Even Hibernate started to release its modules altogether. From the matrix compatibility website:
Please note that as of 3.5.x Hibernate Core, Hibernate Annotations and Hibernate EntityManager are all versioned and released together which greatly simplifies this matrix; see this blog<http://in.relation.to/Bloggers/ClarificationAboutAnnotationsAndEntityManager> for details. So I'm +1 to keep that way. *Bruno Borges* (21) 7672-7099 *www.brunoborges.com* On Mon, Aug 29, 2011 at 11:51 PM, tetsuo <[email protected]> wrote: > The difference is that we would have had a version 2.0, 3.0, 4.0 and 5.0 > before 6.0. Or, more care would be taken to not introduce unnecessary API > incompatibilities (although I can't see any way to avoid it in both 1.3~1.4 > and 1.4~1.5 transitions). > > Oh well, ok, I just like 2.0 better, and I'm making up arguments. :) > > I think I'm more uncomfortable with the rapid release cycle proposed. > > It may work well for browsers, because we just don't care about the > version, > since it gets updated automatically. But I really wouldn't like to use a > library that breaks its API every year (I've always criticized Tapestry for > that). > > Even products like Tomcat, that reached version 7.x (although its first > version was *3.0*, released 12 years ago), take backward compatibility very > seriously (well, also due the fact that the spec itself takes backward > compatibility to the extreme, of course). > > If growing an ecosystem is important for the project, this stability is > essential, or else third-party projects won't even have time to mature > before the next (incompatible) release. > > > > > > On Mon, Aug 29, 2011 at 11:09 PM, Igor Vaynberg <[email protected] > >wrote: > > > On Mon, Aug 29, 2011 at 6:28 PM, tetsuo <[email protected]> wrote: > > > non-binding > > > > > > -1 to independent module versioning. I don't want to have a > compatibility > > > matrix like Hibernate's ( > > > http://community.jboss.org/wiki/HibernateCompatibilityMatrix). > > > > > > +1 to semantic versioning (http://semver.org/) > > > > > > -1 to jump to 6.0, unless it features some major architectural change > > like, > > > make Wicket mostly stateless or something like that. Even with that, > I'd > > > prefer to go with 2.0 instead. Large numbers, for me, indicate bloat > > (with > > > the exception of Chrome, because we don't even care about the version > > number > > > anymore) and instability. > > > > if we followed simver from the beginning the next version would be > > 6.0.0, so what is the difference? > > > > -igor > > >
