Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Corrected API-Calls to Versioning #829

Closed
wants to merge 1 commit into from
Closed

Corrected API-Calls to Versioning #829

wants to merge 1 commit into from

Conversation

sreuterle
Copy link

Versioning methods are called directly on widget instead through widget.paper_trail

Versioning methods are called directly on widget instead through widget.paper_trail
@jaredbeck
Copy link
Member

Thanks Sven, but these changes would be incorrect. For example, widget.live? is actually deprecated in favor of widget.paper_trail.live?. See #719

@jaredbeck jaredbeck closed this Jun 22, 2016
@sreuterle
Copy link
Author

Oh, sorry for that. I've version 5.0.1 installed and there seems to be no widget.paper_trail (for corresponding object for widget). I try to update to latest version. Thanks you :)

@jaredbeck
Copy link
Member

Oh, sorry for that. I've version 5.0.1 installed and there seems to be no widget.paper_trail (for corresponding object for widget). I try to update to latest version. Thanks you :)

widget.paper_trail has not been released yet. You are reading the documentation for the master branch. I'll see if I can clarify that a bit better at the top of the readme.

jaredbeck added a commit that referenced this pull request Jun 22, 2016
People still don't realize that the master readme documents
unreleased features.

e.g. #829

[ci skip]
@sreuterle
Copy link
Author

Maybe it would be better to make a release branch until release so that master corresponds to released version on every time. That's how we handled branches in our company.
Then, of course, the readme would correspond to the released version, too.

@jaredbeck
Copy link
Member

Maybe it would be better to make a release branch until release so that master corresponds to released version on every time.

Thanks for the suggestion, but there is a strong convention in the ruby OSS community that the master branch represents the very latest work, and tags are used for releases. Following the convention has value.

@sreuterle
Copy link
Author

Didn't knew that. Thanks for clarifying!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants