(non-binding) OK, although jumping in late I think the height of the number does not really matter. The only point here (maybe it's just me) that I'm searching maven for the latest versions more frequently than the homepage itself --> It's always a little bit confusing if there are big gaps --> +1 to 3.0.0
@"beeing afraid of jumping versions"; well, in fact wicket breaks api alright between minor versions (Y->(Y+1)) in Martijn's example. Therefore I don't think that there is any difference to what is done now, only that the names really reflect the changes (in ways of semantic versioning). @"word at supporting multible branches"; While those are considered lot's of work (and this might be true using SVN) they are not that painful at all using git-svn and cherry-picks/interactive-rebases. We're developing various versions at the Apache Karaf project side by side and thanks to cherrypick/rebase -i this works really well --> IMHO it should be focused on maybe one api-breaking release a year since many interesting new features can also be done without breaking the api and only making things deprecated (removing them in the next year). This will rather lead to something like X.0.x, X.1.x, X.2.x, X.3.x, X.4.x, (X+1).0.x, ... While I'm a big fan of releasing modules separately I think this is something a community needs to get comfortable with first. Using semantic versioning will be a first step there. There could be e.g. a continuous pom and features.xml helping users to use the correct versions together. Nevertheless, right now -1 for releasing modules separately and change the model a little bit later maybe once the community get's comfortable with the new release model. Kind regards, Andreas On Tue, Aug 30, 2011 at 11:18, Martin Grigorov <[email protected]> wrote: > +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 <[email protected]> > 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 <[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 > >>>> > >>> > > > > > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com <http://jweekend.com/> >
