Apache Wicket › Forum for Wicket Core developers

Next wicket versioning and release schedule

Classic

List

Threaded

11 messages Options

Martijn Dashorst

Next wicket versioning and release schedule

Administrator

I think I can speak for everyone here that our current release has
taken a long time to stabilize, and finalize (and we are not even
there yet!). Given that we are all volunteers and many of us also try
to have a family and/or social life, it is what it is.

When we hit RC status, we should be able to pull out a final release
within weeks, not months. The issue is that none of our users will
actually test prior to us releasing a RC. I think that 1.5 matured
considerably during RC phase, especially since several folks dove in
and started shipping products with it (for better and for worse). It
is a testament to the quality of the software built mostly by Igor,
Juergen, Matej and Martin that our systems haven't had any major issue
with Wicket 1.5 in production use (nothing that couldn't be patched
locally). Kudos to you guys for all the effort and countless hours you
put in!

One thing that anal retentive folks are concerned about is that
breaking API should only be done in major X releases. I've read
statements of folks claiming we are not enterprise ready because we
name our major versions X.Y and even break API in X.Y.Z. While I never
understood the folks with versioning OCD, we can and probably should
improve our versioning strategy even though it currently works for us,
and has worked for us in the last 7 years.

So I propose that we call our next major Wicket version: Wicket 6, and
the major version after that Wicket 7, and the next major version
Wicket 8, etc. New features that don't break API should go into a X.Y
release. Bug fixes that don't break API should go into a X.Y.Z
release.

I propose that we develop breaking API features on trunk until we have
implemented our proposed and scheduled roadmap features, while
continuing to support the previous major release. When we have
finalized our roadmap for the next major release, we create a branch
for it:

branches/wicket-X.x (substitute capital X with the major version number)

From that point on we can continue developing API breaking features on
trunk for X+1, and start bug fixing on Wicket-X.x branch. This will be
a release train that starts with Wicket-X.0.0, and continues until we
deem Wicket-X.0.z stable for general consumption. The Wicket-X.0.z
release will then be a "GA" release. This seems to be how Tomcat works
and other frameworks as well. As long as we don't bless the release
with "GA" I suggest we add a classifier "beta" to the release. This
results in apache-wicket-X.Y.Z-beta.jar, and
apache-wicket-X.Y.Z+1-beta.jar. When our GA release comes I suggest
just dropping the beta-classifier.

If needed we can create feature releases that only add new stuff
without breaking old code in a Wicket-X.y release train. I suggest
making such a train when Wicket-X.0.0 or Wicket-X.0.1 has been
released. I would recommend that we EOL support for the previous Y-1
release as soon as we release a X.Y.0 version. Upgrading would be
easy, and painless. Bug fixes reported against X.Y-1 will be fixed
only in X.Y.z

As far as schedules: I hope to move to two major releases per year: of
the X variant, and two additional releases of the Y variant: so one
year should have: X.0 and X.1, and X+1.0 and X+1.1. This also means a
roughly schedule of 6 months for a new major X release.

Doing this kind of releases on such a schedule takes effort,
discipline and community support. I am willing to step in as a release
manager and perform the wicket next releases and keep an eye out for
JIRA issues and scheduling them to the correct versions.

In my opinion we should number our next Wicket release a major release
and call it: Wicket 6. Rationale: we are going to break API again
(hence a major release), releasing Wicket 2 would be problematic with
search engines discovering old wicket 2 threads and such, I would
+1000 a move to Java 6 as our minimum requirement and -1 staying at
Java 5, and there's precedent of going from a 1.5 release train to big
number 6.

I'll launch a separate roadmap discussion for what should and
shouldn't go into Wicket 6, so please no discussions of whether a Java
6 base requirement is warranted or not. That is for a new thread
titled "Roadmap for Wicket 6" posted to the dev@ list.

Martijn

Igor Vaynberg-2

Re: Next wicket versioning and release schedule

+1

-igor

On Mon, Aug 29, 2011 at 3:15 PM, Martijn Dashorst
<[hidden email]> wrote:

> I think I can speak for everyone here that our current release has
> taken a long time to stabilize, and finalize (and we are not even
> there yet!). Given that we are all volunteers and many of us also try
> to have a family and/or social life, it is what it is.
>
> When we hit RC status, we should be able to pull out a final release
> within weeks, not months. The issue is that none of our users will
> actually test prior to us releasing a RC. I think that 1.5 matured
> considerably during RC phase, especially since several folks dove in
> and started shipping products with it (for better and for worse). It
> is a testament to the quality of the software built mostly by Igor,
> Juergen, Matej and Martin that our systems haven't had any major issue
> with Wicket 1.5 in production use (nothing that couldn't be patched
> locally). Kudos to you guys for all the effort and countless hours you
> put in!
>
> One thing that anal retentive folks are concerned about is that
> breaking API should only be done in major X releases. I've read
> statements of folks claiming we are not enterprise ready because we
> name our major versions X.Y and even break API in X.Y.Z. While I never
> understood the folks with versioning OCD, we can and probably should
> improve our versioning strategy even though it currently works for us,
> and has worked for us in the last 7 years.
>
> So I propose that we call our next major Wicket version: Wicket 6, and
> the major version after that Wicket 7, and the next major version
> Wicket 8, etc. New features that don't break API should go into a X.Y
> release. Bug fixes that don't break API should go into a X.Y.Z
> release.
>
> I propose that we develop breaking API features on trunk until we have
> implemented our proposed and scheduled roadmap features, while
> continuing to support the previous major release. When we have
> finalized our roadmap for the next major release, we create a branch
> for it:
>
> branches/wicket-X.x (substitute capital X with the major version number)
>
> From that point on we can continue developing API breaking features on
> trunk for X+1, and start bug fixing on Wicket-X.x branch. This will be
> a release train that starts with Wicket-X.0.0, and continues until we
> deem Wicket-X.0.z stable for general consumption. The Wicket-X.0.z
> release will then be a "GA" release. This seems to be how Tomcat works
> and other frameworks as well. As long as we don't bless the release
> with "GA" I suggest we add a classifier "beta" to the release. This
> results in apache-wicket-X.Y.Z-beta.jar, and
> apache-wicket-X.Y.Z+1-beta.jar. When our GA release comes I suggest
> just dropping the beta-classifier.
>
> If needed we can create feature releases that only add new stuff
> without breaking old code in a Wicket-X.y release train. I suggest
> making such a train when Wicket-X.0.0 or Wicket-X.0.1 has been
> released. I would recommend that we EOL support for the previous Y-1
> release as soon as we release a X.Y.0 version. Upgrading would be
> easy, and painless. Bug fixes reported against X.Y-1 will be fixed
> only in X.Y.z
>
> As far as schedules: I hope to move to two major releases per year: of
> the X variant, and two additional releases of the Y variant: so one
> year should have: X.0 and X.1, and X+1.0 and X+1.1. This also means a
> roughly schedule of 6 months for a new major X release.
>
> Doing this kind of releases on such a schedule takes effort,
> discipline and community support. I am willing to step in as a release
> manager and perform the wicket next releases and keep an eye out for
> JIRA issues and scheduling them to the correct versions.
>
> In my opinion we should number our next Wicket release a major release
> and call it: Wicket 6. Rationale: we are going to break API again
> (hence a major release), releasing Wicket 2 would be problematic with
> search engines discovering old wicket 2 threads and such, I would
> +1000 a move to Java 6 as our minimum requirement and -1 staying at
> Java 5, and there's precedent of going from a 1.5 release train to big
> number 6.
>
> I'll launch a separate roadmap discussion for what should and
> shouldn't go into Wicket 6, so please no discussions of whether a Java
> 6 base requirement is warranted or not. That is for a new thread
> titled "Roadmap for Wicket 6" posted to the dev@ list.
>
> Martijn
>

Brian Topping

Re: Next wicket versioning and release schedule

In reply to this post by Martijn Dashorst

-1

I propose that Wicket modules be released separately. Projects that are small can be released as a monolithic whole. Wicket is no longer a small project. With the changes that went into 1.5 to make it easier to program, there should be very few changes in the core modules.

Maven provides very robust facilities for version ranges that can make sure modules avoid incompatibilities. The rules of when to update these version ranges is very easy to follow. I would be very surprised if anyone was incapable of doing it well. Basically, version ranges of dependencies are kept "open" until there is an API change that requires it to be closed at some milestone.

At the end of the day, it doesn't matter really matter how versions are named, what matters is that users expectations are met. I've already referenced Wikipedia entries that cover pretty commonly held expectations that people have, what is proposed here is not far from them. Again, whatever scheme is chosen just needs to be documented and adhered to.

Brian

p.s. I am presuming I am one of the "anal retentive folks with versioning OCD". Congrats on keeping it classy!

On Aug 29, 2011, at 6:15 PM, Martijn Dashorst wrote:

tetsuo

Re: Next wicket versioning and release schedule

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 look to some very stable projects, they are
still in their 2.x or 3.x versions, even with almost, or more than, a decade
of history (Apache HTTPD, Linux, Spring, Apache Commons). Tomcat only is at
version 7 because it increments every time the specs versions change. But
which quality Java framework has such a high version number?

Tetsuo

On Mon, Aug 29, 2011 at 8:36 PM, Brian Topping <[hidden email]> wrote:

> -1
>
> I propose that Wicket modules be released separately. Projects that are
> small can be released as a monolithic whole. Wicket is no longer a small
> project. With the changes that went into 1.5 to make it easier to program,
> there should be very few changes in the core modules.
>
> Maven provides very robust facilities for version ranges that can make sure
> modules avoid incompatibilities. The rules of when to update these version
> ranges is very easy to follow. I would be very surprised if anyone was
> incapable of doing it well. Basically, version ranges of dependencies are
> kept "open" until there is an API change that requires it to be closed at
> some milestone.
>
> At the end of the day, it doesn't matter really matter how versions are
> named, what matters is that users expectations are met. I've already
> referenced Wikipedia entries that cover pretty commonly held expectations
> that people have, what is proposed here is not far from them. Again,
> whatever scheme is chosen just needs to be documented and adhered to.
>
> Brian
>
> p.s. I am presuming I am one of the "anal retentive folks with versioning
> OCD". Congrats on keeping it classy!
>
> On Aug 29, 2011, at 6:15 PM, Martijn Dashorst wrote:
>
> > I think I can speak for everyone here that our current release has
> > taken a long time to stabilize, and finalize (and we are not even
> > there yet!). Given that we are all volunteers and many of us also try
> > to have a family and/or social life, it is what it is.
> >
> > When we hit RC status, we should be able to pull out a final release
> > within weeks, not months. The issue is that none of our users will
> > actually test prior to us releasing a RC. I think that 1.5 matured
> > considerably during RC phase, especially since several folks dove in
> > and started shipping products with it (for better and for worse). It
> > is a testament to the quality of the software built mostly by Igor,
> > Juergen, Matej and Martin that our systems haven't had any major issue
> > with Wicket 1.5 in production use (nothing that couldn't be patched
> > locally). Kudos to you guys for all the effort and countless hours you
> > put in!
> >
> > One thing that anal retentive folks are concerned about is that
> > breaking API should only be done in major X releases. I've read
> > statements of folks claiming we are not enterprise ready because we
> > name our major versions X.Y and even break API in X.Y.Z. While I never
> > understood the folks with versioning OCD, we can and probably should
> > improve our versioning strategy even though it currently works for us,
> > and has worked for us in the last 7 years.
> >
> > So I propose that we call our next major Wicket version: Wicket 6, and
> > the major version after that Wicket 7, and the next major version
> > Wicket 8, etc. New features that don't break API should go into a X.Y
> > release. Bug fixes that don't break API should go into a X.Y.Z
> > release.
> >
> > I propose that we develop breaking API features on trunk until we have
> > implemented our proposed and scheduled roadmap features, while
> > continuing to support the previous major release. When we have
> > finalized our roadmap for the next major release, we create a branch
> > for it:
> >
> > branches/wicket-X.x (substitute capital X with the major version
> number)
> >
> > From that point on we can continue developing API breaking features on
> > trunk for X+1, and start bug fixing on Wicket-X.x branch. This will be
> > a release train that starts with Wicket-X.0.0, and continues until we
> > deem Wicket-X.0.z stable for general consumption. The Wicket-X.0.z
> > release will then be a "GA" release. This seems to be how Tomcat works
> > and other frameworks as well. As long as we don't bless the release
> > with "GA" I suggest we add a classifier "beta" to the release. This
> > results in apache-wicket-X.Y.Z-beta.jar, and
> > apache-wicket-X.Y.Z+1-beta.jar. When our GA release comes I suggest
> > just dropping the beta-classifier.
> >
> > If needed we can create feature releases that only add new stuff
> > without breaking old code in a Wicket-X.y release train. I suggest
> > making such a train when Wicket-X.0.0 or Wicket-X.0.1 has been
> > released. I would recommend that we EOL support for the previous Y-1
> > release as soon as we release a X.Y.0 version. Upgrading would be
> > easy, and painless. Bug fixes reported against X.Y-1 will be fixed
> > only in X.Y.z
> >
> > As far as schedules: I hope to move to two major releases per year: of
> > the X variant, and two additional releases of the Y variant: so one
> > year should have: X.0 and X.1, and X+1.0 and X+1.1. This also means a
> > roughly schedule of 6 months for a new major X release.
> >
> > Doing this kind of releases on such a schedule takes effort,
> > discipline and community support. I am willing to step in as a release
> > manager and perform the wicket next releases and keep an eye out for
> > JIRA issues and scheduling them to the correct versions.
> >
> > In my opinion we should number our next Wicket release a major release
> > and call it: Wicket 6. Rationale: we are going to break API again
> > (hence a major release), releasing Wicket 2 would be problematic with
> > search engines discovering old wicket 2 threads and such, I would
> > +1000 a move to Java 6 as our minimum requirement and -1 staying at
> > Java 5, and there's precedent of going from a 1.5 release train to big
> > number 6.
> >
> > I'll launch a separate roadmap discussion for what should and
> > shouldn't go into Wicket 6, so please no discussions of whether a Java
> > 6 base requirement is warranted or not. That is for a new thread
> > titled "Roadmap for Wicket 6" posted to the dev@ list.
> >
> > Martijn
> >
>
>

Brian Topping

Re: Next wicket versioning and release schedule

I'm revising my vote to agree with Tetsuo on all three of his aspects. (That semver.org link is an excellent and concise capture of everything I have been trying to advocate, thank you for providing it!)

Regarding semantic versioning, note the paragraph starting with "A simple example will demonstrate how Semantic Versioning can make dependency hell a thing of the past." This is *exactly* what I am talking about with independent module versioning. Version ranges completely avoid a compatibility matrix.

Brian

On Aug 29, 2011, at 9:28 PM, tetsuo 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 look to some very stable projects, they are
> still in their 2.x or 3.x versions, even with almost, or more than, a decade
> of history (Apache HTTPD, Linux, Spring, Apache Commons). Tomcat only is at
> version 7 because it increments every time the specs versions change. But
> which quality Java framework has such a high version number?
>
> Tetsuo
>
>
>
> On Mon, Aug 29, 2011 at 8:36 PM, Brian Topping <[hidden email]> wrote:
>
>> -1
>>
>> I propose that Wicket modules be released separately. Projects that are
>> small can be released as a monolithic whole. Wicket is no longer a small
>> project. With the changes that went into 1.5 to make it easier to program,
>> there should be very few changes in the core modules.
>>
>> Maven provides very robust facilities for version ranges that can make sure
>> modules avoid incompatibilities. The rules of when to update these version
>> ranges is very easy to follow. I would be very surprised if anyone was
>> incapable of doing it well. Basically, version ranges of dependencies are
>> kept "open" until there is an API change that requires it to be closed at
>> some milestone.
>>
>> At the end of the day, it doesn't matter really matter how versions are
>> named, what matters is that users expectations are met. I've already
>> referenced Wikipedia entries that cover pretty commonly held expectations
>> that people have, what is proposed here is not far from them. Again,
>> whatever scheme is chosen just needs to be documented and adhered to.
>>
>> Brian
>>
>> p.s. I am presuming I am one of the "anal retentive folks with versioning
>> OCD". Congrats on keeping it classy!
>>
>> On Aug 29, 2011, at 6:15 PM, Martijn Dashorst wrote:
>>
>>> I think I can speak for everyone here that our current release has
>>> taken a long time to stabilize, and finalize (and we are not even
>>> there yet!). Given that we are all volunteers and many of us also try
>>> to have a family and/or social life, it is what it is.
>>>
>>> When we hit RC status, we should be able to pull out a final release
>>> within weeks, not months. The issue is that none of our users will
>>> actually test prior to us releasing a RC. I think that 1.5 matured
>>> considerably during RC phase, especially since several folks dove in
>>> and started shipping products with it (for better and for worse). It
>>> is a testament to the quality of the software built mostly by Igor,
>>> Juergen, Matej and Martin that our systems haven't had any major issue
>>> with Wicket 1.5 in production use (nothing that couldn't be patched
>>> locally). Kudos to you guys for all the effort and countless hours you
>>> put in!
>>>
>>> One thing that anal retentive folks are concerned about is that
>>> breaking API should only be done in major X releases. I've read
>>> statements of folks claiming we are not enterprise ready because we
>>> name our major versions X.Y and even break API in X.Y.Z. While I never
>>> understood the folks with versioning OCD, we can and probably should
>>> improve our versioning strategy even though it currently works for us,
>>> and has worked for us in the last 7 years.
>>>
>>> So I propose that we call our next major Wicket version: Wicket 6, and
>>> the major version after that Wicket 7, and the next major version
>>> Wicket 8, etc. New features that don't break API should go into a X.Y
>>> release. Bug fixes that don't break API should go into a X.Y.Z
>>> release.
>>>
>>> I propose that we develop breaking API features on trunk until we have
>>> implemented our proposed and scheduled roadmap features, while
>>> continuing to support the previous major release. When we have
>>> finalized our roadmap for the next major release, we create a branch
>>> for it:
>>>
>>> branches/wicket-X.x (substitute capital X with the major version
>> number)
>>>
>>> From that point on we can continue developing API breaking features on
>>> trunk for X+1, and start bug fixing on Wicket-X.x branch. This will be
>>> a release train that starts with Wicket-X.0.0, and continues until we
>>> deem Wicket-X.0.z stable for general consumption. The Wicket-X.0.z
>>> release will then be a "GA" release. This seems to be how Tomcat works
>>> and other frameworks as well. As long as we don't bless the release
>>> with "GA" I suggest we add a classifier "beta" to the release. This
>>> results in apache-wicket-X.Y.Z-beta.jar, and
>>> apache-wicket-X.Y.Z+1-beta.jar. When our GA release comes I suggest
>>> just dropping the beta-classifier.
>>>
>>> If needed we can create feature releases that only add new stuff
>>> without breaking old code in a Wicket-X.y release train. I suggest
>>> making such a train when Wicket-X.0.0 or Wicket-X.0.1 has been
>>> released. I would recommend that we EOL support for the previous Y-1
>>> release as soon as we release a X.Y.0 version. Upgrading would be
>>> easy, and painless. Bug fixes reported against X.Y-1 will be fixed
>>> only in X.Y.z
>>>
>>> As far as schedules: I hope to move to two major releases per year: of
>>> the X variant, and two additional releases of the Y variant: so one
>>> year should have: X.0 and X.1, and X+1.0 and X+1.1. This also means a
>>> roughly schedule of 6 months for a new major X release.
>>>
>>> Doing this kind of releases on such a schedule takes effort,
>>> discipline and community support. I am willing to step in as a release
>>> manager and perform the wicket next releases and keep an eye out for
>>> JIRA issues and scheduling them to the correct versions.
>>>
>>> In my opinion we should number our next Wicket release a major release
>>> and call it: Wicket 6. Rationale: we are going to break API again
>>> (hence a major release), releasing Wicket 2 would be problematic with
>>> search engines discovering old wicket 2 threads and such, I would
>>> +1000 a move to Java 6 as our minimum requirement and -1 staying at
>>> Java 5, and there's precedent of going from a 1.5 release train to big
>>> number 6.
>>>
>>> I'll launch a separate roadmap discussion for what should and
>>> shouldn't go into Wicket 6, so please no discussions of whether a Java
>>> 6 base requirement is warranted or not. That is for a new thread
>>> titled "Roadmap for Wicket 6" posted to the dev@ list.
>>>
>>> Martijn
>>>
>>
>>

Igor Vaynberg-2

Re: Next wicket versioning and release schedule

In reply to this post by tetsuo

On Mon, Aug 29, 2011 at 6:28 PM, tetsuo <[hidden email]> wrote:

if we followed simver from the beginning the next version would be
6.0.0, so what is the difference?

-igor

tetsuo

Re: Next wicket versioning and release schedule

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 <[hidden email]>wrote:

> On Mon, Aug 29, 2011 at 6:28 PM, tetsuo <[hidden email]> 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
>

Bruno Borges

Re: Next wicket versioning and release schedule

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 <[hidden email]> 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 <[hidden email]
> >wrote:
>
> > On Mon, Aug 29, 2011 at 6:28 PM, tetsuo <[hidden email]> 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
> >
>

Brian Topping

Re: Next wicket versioning and release schedule

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 <[hidden email]> 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 <[hidden email]
>>> wrote:
>>
>>> On Mon, Aug 29, 2011 at 6:28 PM, tetsuo <[hidden email]> 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-4

Re: Next wicket versioning and release schedule

+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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
>>>> wrote:
>>>
>>>> On Mon, Aug 29, 2011 at 6:28 PM, tetsuo <[hidden email]> 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

pieber

Re: Next wicket versioning and release schedule

(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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <
> [hidden email]
> >>>> wrote:
> >>>
> >>>> On Mon, Aug 29, 2011 at 6:28 PM, tetsuo <[hidden email]>
> 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/>
>