Hello Vladislav, > Well, patch is a patch ;) It's just a correction for bugs. And I think a > release should not contain both bugfixes and new features. Either one or > another, not both together. If you use some good version control software, > that shouldn't be a problem.
The problem is not the version control system (SVN or Git). The problem is time. Maintaining several branches at the same time can be tedious, especially when SVN is as slow as that of sourceforge, but that's another story. Maybe that'll be a reason to finally abandon SVN and only use Git/GitHub > I would prefer to see third version number digit changed if only bugfixes > are introduced and I need to upgrade my project to use new Jooq version. > > I would prefer to see second version number digit changed if some new > functionality was added [...] > > I would prefer to see first version digit changed if public API has changed > [...] I agree with that, in general, and I like your link. I'm trying to follow the first digit policy as much as possible. jOOQ's other two digits might be a bit funky though. I should try maintaining branches for a while, measuring the true demand for branching by checking download statistics. So next release will be 2.1.0 and 2.0.6 for bugfixes off 2.0.5 Do you have a similar resource that describes optimal iteration planning? I like to release early and often, having new features confirmed by many users. Currently, I'm releasing what you would call a "minor release" (new features) every 2-3 weeks (this would probably become 3-4 weeks with branching). How about patch releases? With so many minor releases, I'd start new branches every 2-3 / 3-4 weeks too. Are there best practices? i.e. I wouldn't merge trivial bugfixes to branches. How often would branched patch releases be delivered? Thanks for your input Cheers Lukas PS: Anyone else following this (including Vladislav! :), if you feel like becoming a branch master for jOOQ, your help would be greatly appreciated!
