I admit to not reading the whole thing, but in general I agree with Major.Minor.Patch. As for how it applies to Log4j, Users of the public part of the API should be guaranteed compatibility. Users building their own custom components such as Appenders, Layouts, Filters, etc, that are supported as plugins should be guaranteed as much compatibility as possible. Deviations from this are serious and could result in a new Major version. Changes in behavior that change the default behavior of components should/could also result in a new major version. Changes in behavior to existing components through the addition of new parameters, the addition of new components, or other behavioral changes would likely result in a new minor version. Bug fixes or changes that will likely not be noticeable by users would result in a new patch version.
Ralph On Jul 13, 2014, at 8:22 AM, 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 --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
