-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Create branches and tags #187
Comments
I created branches for My thought is that the flow will go:
Then we need I haven't thought into version numbers yet... Any suggestions on where to start the version numbering? https://github.com/evocateur/js-beautify has a "v0.3.5" as current, but I suspect he just picked that out of the air. |
I think that the current version should be released as 1.0.0 (it is already in production after all) and then try semver'ish updates. Do we need some kind of wordpress-ish blog now for announces? Does anyone care? |
I'm following the semver.org faq, "If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.". We pass, what we have — even if somewhat chaotic and disorganized — is 1.0. Nothing wrong with that. |
Heh. :) I'd still be uncomfortable calling the current master 1.0. Take a look at the point I just chose for sync-stable. It includes wordwrap but leaves out the inline-statement handling which is still stablizing and needs syncing. Could we call that 1.0? |
I'm in no hurry to push out something. If you think that it'd be better if we first get the node and pypi packaging together in a nice way, maybe clean up some api/option cruft, and then release a shiny clean 1.0 package, I'm perfectly ok with that :) |
Yeah, I would definitely not follow my versioning on the node package. (I started at 0.1.0, as is convention with npm modules, and have mostly followed semver since) I would prefer delaying a formal 1.0.0 until we have the npm and pypi ducks all in a row. That being done, we can keep the version for all three(?) distributions in step. To that end, I'll be making that pull request I threatened myself with last week momentarily. |
I've created |
We tend to think of git/github as a low risk thing. "Don't worry, it's in git." But, tagging comes "with great power" and some subtle consequences. We need to make sure that before we tag, we rev the relevant version numbers. I found version numbers in: There should also probably be one in: Anyway, I changed the version number in python/setup.py before pushing the update to pypi. I've sent a pull request #208 and think this should also be merged to master. (I think I have the ability to do this myself, but with Travis failing I'm going to wait and see what others have to say.) |
@RichardBronosky Thanks for the heads up! That helped me produce a working package on pypi. I picked 1.2.0 as the new version to avoid conflicts with any previous numbering schemes. Sorry, if I jumped the gun but I've been itching land this. Next time, we can do a milestone and reach agreement before pulling the trigger. Opened #214 to say we need to document this a bit further, but I think we're in a good state on branches and tags. now. |
As pointed out elsewhere, we need some branches and tags to track releases, stability, and continuing features.
The text was updated successfully, but these errors were encountered: