Few comments. It would be good to get your roadmap, Git branching/merging, and version number policy documented.
At Apache CouchDB, we're attempting to do something along those lines with these: http://wiki.apache.org/couchdb/Roadmap_Process http://wiki.apache.org/couchdb/Merge_Procedure (Summary: work happens on master, new release branches are created immediately after each release, features are merged in once they're ready, along with tests, docs, etc, etc. Simplifies the eventual process of cutting a release.) We're still working it out though, so it's just a data point. As for when to bump to 5.0. Do that whenever you introduce breaking changes. Preferably along with the commit. (That is, major revisions, IMO should be tied to breaking changes, not marketing efforts.) cf. http://semver.org/ On Mon, Oct 1, 2012 at 6:34 PM, Hugo Trippaers < [email protected]> wrote: > Heya all, > > With the 4.0.0 branch ready for the final stages toward the release I > think it's time to up the version number of the master branch. If there are > no objections I will go ahead and change the version number of master to > 4.1.0. > > I think for the future this should happen directly after we make a branch > for a release so it is very clear what versions people are working on and > prevents mismatches from happening when people are working on both the > branch and the master at the same time. We don't want somebody pulling in a > dependency from that master branch into the release compile just because it > compiled more recently ;-) > > Cheers, > > Hugo > -- NS
