They also run parallel development tracks on multiple versions, providing a different means of solving the same problem.
On Aug 29, 2011, at 11:33 PM, Bruno Borges wrote: > 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 >>> >>
