We have a tag so a branch can be made at any time. But I don't know of any ASF project that does "release maintenance" - everybody just does fixes as we have here and then creates a new release with whatever fixes and enhancements are there. The only exceptions to this would be security bugs or critical fixes, but a lot of times those just force a release as soon as the fix is committed.
Ralph > On Jul 13, 2014, at 12:07 PM, Matt Sicker <boa...@gmail.com> wrote: > > I think it's a good idea to keep old release branches for security fixes and > such. Otherwise, mainline trunk development seems to make sense to me. > > >> On 13 July 2014 10:22, Gary Gregory <garydgreg...@gmail.com> wrote: >> FYI http://semver.org/ >> >> Gary >> >> >> -------- Original message -------- >> From: Gary Gregory >> Date:07/13/2014 09:59 (GMT-05:00) >> To: Log4J Developers List >> Subject: RE: Versioning/branching after 2.0 release >> >> I think we just work as usual in trunk and release when ready and use >> semantic versioning. No need to maintain branches unless absolutely >> necessary. API breakage is only for major versions. We need to decide if >> that is just for the API module or all modules. >> >> Gary >> >> >> -------- Original message -------- >> From: Remko Popma >> Date:07/13/2014 09:39 (GMT-05:00) >> To: Log4J Developers List >> Subject: Versioning/branching after 2.0 release >> >> After the 2.0 release, how are we going to do versioning? >> >> One idea is to have 2.0.x releases with bugfixes only, where new features >> and any API changes would go into a 2.1 release. >> >> Another way of doing this is to simply have a 2.1 release next containing >> both bugfixes and new features as well as API changes if any. >> >> And perhaps there are other ways... >> >> I don't have a strong preference about this but it may be good to discuss >> this since it may determine how we do branching going forward. >> >> Thoughts? >> >> Remko > > > > -- > Matt Sicker <boa...@gmail.com>
