Create branches and tags

[bitwiseman]

As pointed out elsewhere, we need some branches and tags to track releases, stability, and continuing features.

[bitwiseman]

I created branches for sync and sync-stable, and set them to reasonable points in the past month.

My thought is that the flow will go:

master -> sync -> sync-stable

Then we need node-package and pypi-package branches, probably off of master, for the package releases. The web package already exists in gh-pages, right?

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.

[einars]

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?

[bitwiseman]

I was going to suggest the 1.0.0 at a significantly earlier point in time. If we're talking milestones, there are several open issues (including #181 and #174, and sync-ing again) that need to fix before we call it ready for release.

[einars]

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.

[bitwiseman]

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?

[einars]

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 :)

[evocateur]

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.

[bitwiseman]

I've created node-stable and python-stable branches. I've notched the sync and all the stable branches to the 0.4.2 commit - might be a little presumptuous, but let's go with it.

[RichardBronosky]

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:
package.json
python/setup.py

There should also probably be one in:
php/jsbeautifier.php
...though I doubt it should be up to 0.4.2 based on #207

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.)

[bitwiseman]

@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.