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 >
