+1 for semver +1 for next major version to be either 3.0.0 or 6.0.0 reasoning: - skip 2.0.0 to not confuse with 2.0-DISCONTINUED branch - 6.0.0 is related somehow to 1.6 (next version if we continue with the current way) and it also be related to JDK6 requirement I'm more in favour of 3.0.0 because Wicket 7.0.0 will not require JDK7, and because I guess there will be flames like "Wicket 6.0.0 > Tapestry 5.3.0" -1 for sub-modules released independently. This will make both the release process harder and confusing for the users
On Tue, Aug 30, 2011 at 6:10 AM, Brian Topping <topp...@codehaus.org> wrote: > 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 <ronald.tet...@gmail.com> 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 <igor.vaynb...@gmail.com >>>> wrote: >>> >>>> On Mon, Aug 29, 2011 at 6:28 PM, tetsuo <ronald.tet...@gmail.com> 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 >>>> >>> > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
