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

Please tag stable releases #1

Closed
sjl opened this issue Mar 24, 2010 · 3 comments
Closed

Please tag stable releases #1

sjl opened this issue Mar 24, 2010 · 3 comments

Comments

@sjl
Copy link
Contributor

sjl commented Mar 24, 2010

This would help us out a lot.

We're using page-cms quite a bit and it would be handy to be able to pull down a consistent, working version when deploying without worrying about any changes made since the last time we pulled.

Using semantic versioning would be awesome: http://semver.org/

@batiste
Copy link
Owner

batiste commented Mar 24, 2010

I will start to follow this semantic versioning scheme in addition to the changelog.

Thanks for the input. Can I ask how you use the version number in your deployement? Are you able to tell pip to update a package in this way:

django-page-cms>=1.2.0<1.3.0

Meaning that is take the latest backward compatible package for 1.2?

@sjl
Copy link
Contributor Author

sjl commented Mar 24, 2010

You can do something like that, but usually I prefer using source checkouts (so I can directly patch & commit if I find a bug):

pip install -e git://github.com/dwaiter/django-page-cms@v1.1.1#egg=whatever

So it will always stay at that version until I manually update it. Semantic versioning just makes it easier for me to look at the new tag and tell how much is going to break if I update.

I could probably set up something similar to what you described (tell pip to automatically update if it won't break anything) but I'd want to test it anyway to be sure, so it's not a big priority.

@batiste
Copy link
Owner

batiste commented May 7, 2010

Hum I kind of fail on the latest release 1.1.3. I should have incread Y (X.Y.Z) because there was new features. The release should be backward compatible anyway.

@batiste batiste closed this as completed Jun 1, 2011
batiste pushed a commit that referenced this issue Aug 3, 2013
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

No branches or pull requests

2 participants