You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Igor Vaynberg <ig...@gmail.com> on 2007/03/08 02:30:27 UTC
roadmap
pasted from almaw's email on @user
-igor
-------------------------- 8>< --------------------------------------------
In my opinion we could, within the next:
-----------------------------------------
1 week - Push 1.3-betas as-is.
2/3 weeks - Bug fix as people test it and push out rc's when
we feel it's solid and stable.
4 weeks - Rename 1.x branch to 1.3.x.
- Release 1.3.0 final and put 1.3.x immediately into
maintenance mode.
- Create 1.4.x branch from 1.3.0 tag.
- Merge the model changes from trunk to 1.4.x.
- Backport anything else from trunk to 1.4.x that's
not JDK5-specific.
6 weeks - Push out 1.4-betas
7/8 weeks - Push out 1.4-rc's
9 weeks - Push out 1.4.0 final
- Create 1.5.x branch from 1.4.0 tag.
- Backport/add generics, covariance and other JDK 5 trunk
features to the 1.5.x branch.
- Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
14+ weeks - Release 1.5.0
Suggestions to make this work:
------------------------------
We won't backport from 1.4.x -> 1.3.x.
We won't actively develop trunk.
We will push 1.4 out very soon after 1.3, and encourage migration.
We will have this in a public roadmap so people can see it coming.
Notes on what you think is insanity, but actually isn't:
--------------------------------------------------------
We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
1.5.x and what's currently trunk). This may seem like madness to you,
but I reckon it isn't:
During 1.3 development, 2.x is low activity, 1.2.x negligible.
During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
During 1.5 development, only 1.4.x will also be quite active.
Once 1.5.0 is out, we can properly deprecate 2.0. People currently using
it may not like being told to migrate to 1.5.x, but that shouldn't be
too hard (much less hard than going from 1.3->2.0) and there shouldn't
be too many of them. I guess that's the price you sometimes pay for
using unreleased software. :-/
I'd envisage 1.4.x will require some backports from 1.5.x. We'd
obviously encourage core developers and patchers to upgrade their sites
to use 1.5.x, do active development on that, and therefore try to only
ever backport from 1.5.x to 1.4.x, not forward-port the other way around.
If you think I'm smoking crack, the above is utterly unreasonable, you
want to kick me out of the gang, or you have any better ideas or
suggestions as to how to keep everyone happy, please shout now. :-)
Best regards,
Alastair
Re: [Vote] roadmap
Posted by Eelco Hillenius <ee...@gmail.com>.
> > 9 weeks is definitley too long for current 2.0 users to wait
> > before. We all know that 1 week in developer terms is 2 or 3
> > human weeks, so this really leaves us high and dry with no
> > viable codebase for a long period of time. I'm sure for most of
> > us that means backporting to 1.3, then forwardporting again to
> > 1.5. That will be really unpleasant -- please don't do that!
>
> By reading your message, I'm under the impression that trunk will
> suddenly collapse and disappear! Why do you have that feeling?
> The code will remain as-is, you will still be able to work on your
> projects, don't worry.
I (and Johan) agree with James though. If you're on a project that
uses 2.0 and we decide to discontinue it, you want to upgrade asap to
a version that will be maintained in the future. And of course, we
should want that too, as the sooner users migrate, the sooner we can
actually close that branch.
Eelco
Re: [Vote] roadmap
Posted by Igor Vaynberg <ig...@gmail.com>.
no you wont see any exciting new features being developed. we are going to
concentrate on backporting all the good 2.0 stuff into 1.x before we work on
anything new.
-igor
On 3/8/07, James McLaughlin <jo...@gmail.com> wrote:
>
> On 3/8/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
> >
> > * James McLaughlin:
> >
> > > 9 weeks is definitley too long for current 2.0 users to wait
> > > before. We all know that 1 week in developer terms is 2 or 3
> > > human weeks, so this really leaves us high and dry with no
> > > viable codebase for a long period of time. I'm sure for most of
> > > us that means backporting to 1.3, then forwardporting again to
> > > 1.5. That will be really unpleasant -- please don't do that!
> >
> > By reading your message, I'm under the impression that trunk will
> > suddenly collapse and disappear! Why do you have that feeling?
> > The code will remain as-is, you will still be able to work on your
> > projects, don't worry.
> > --
>
>
> By reading this thread, I get the impression many wicket developers wish
> it
> would :). Let's just say at best 2.0 will be on life-support and waiting
> to
> be euthanized. The wicket developers are a creative and prolific bunch, so
> I'll have the added frutstration of watching many excellent new features
> be
> developed just beyond the glass in 1.x land. If that's what I wanted, I
> would have stayed with 1.2. I've had enough of that as I have watched 2.0be
> abandoned over that past month or so in favor of 1.3
>
> regards,
>
> jim
>
> > Jean-Baptiste Quenot
> > aka John Banana Qwerty
> > http://caraldi.com/jbq/
> >
>
Re: [Vote] roadmap
Posted by James McLaughlin <jo...@gmail.com>.
On 3/8/07, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> * James McLaughlin:
>
> > 9 weeks is definitley too long for current 2.0 users to wait
> > before. We all know that 1 week in developer terms is 2 or 3
> > human weeks, so this really leaves us high and dry with no
> > viable codebase for a long period of time. I'm sure for most of
> > us that means backporting to 1.3, then forwardporting again to
> > 1.5. That will be really unpleasant -- please don't do that!
>
> By reading your message, I'm under the impression that trunk will
> suddenly collapse and disappear! Why do you have that feeling?
> The code will remain as-is, you will still be able to work on your
> projects, don't worry.
> --
By reading this thread, I get the impression many wicket developers wish it
would :). Let's just say at best 2.0 will be on life-support and waiting to
be euthanized. The wicket developers are a creative and prolific bunch, so
I'll have the added frutstration of watching many excellent new features be
developed just beyond the glass in 1.x land. If that's what I wanted, I
would have stayed with 1.2. I've had enough of that as I have watched 2.0 be
abandoned over that past month or so in favor of 1.3
regards,
jim
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
Re: [Vote] roadmap
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* James McLaughlin:
> 9 weeks is definitley too long for current 2.0 users to wait
> before. We all know that 1 week in developer terms is 2 or 3
> human weeks, so this really leaves us high and dry with no
> viable codebase for a long period of time. I'm sure for most of
> us that means backporting to 1.3, then forwardporting again to
> 1.5. That will be really unpleasant -- please don't do that!
By reading your message, I'm under the impression that trunk will
suddenly collapse and disappear! Why do you have that feeling?
The code will remain as-is, you will still be able to work on your
projects, don't worry.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: [Vote] roadmap
Posted by James McLaughlin <jo...@gmail.com>.
9 weeks is definitley too long for current 2.0 users to wait before. We all
know that 1 week in developer terms is 2 or 3 human weeks, so this really
leaves us high and dry with no viable codebase for a long period of time.
I'm sure for most of us that means backporting to 1.3, then forwardporting
again to 1.5. That will be really unpleasant -- please don't do that!
On 3/8/07, Johan Compagner <jc...@gmail.com> wrote:
>
> exactly my point.
>
>
> On 3/8/07, Jonathan Locke <jo...@gmail.com> wrote:
> >
> >
> >
> > this feels too aggressive to me if 1.3 is to be released through
> > apache. we
> > want our first apache release to be the best it can be, not as fast as
> it
> > can be because we've been promising it for a while. let's give
> ourselves
> > a
> > break and take the extra days it takes to backport model changes and
> > important features to 1.3. if it takes even another month, it's still
> > better because our story of what to use is more understandable...
> 1.4should
> > really just be 1.3 + generics changes. that's very simple to explain.
> >
> > btw, let's not kick ourselves for working on 2.0 for a long time and
> > falling
> > behind our earlier promises of scheduling. unpredictable things have
> > happened and these kinds of things happen even on the best projects. to
> > our
> > great credit, we've shown a willingness to evaluate our own work, suck
> it
> > up
> > and kill our darlings, as someone said. that's what makes something
> > great.
> > let's not push out a 1.3 that's less than it should be to meet a
> schedule
> > we
> > simply couldn't meet due to unforseen circumstances. i vote to slow
> down
> > in
> > spite of any scheduling pressure we may be feeling.
> >
> > jon
> >
> >
> > igor.vaynberg wrote:
> > >
> > > pasted from almaw's email on @user
> > >
> > > -igor
> > >
> > > -------------------------- 8><
> > > --------------------------------------------
> > >
> > > In my opinion we could, within the next:
> > > -----------------------------------------
> > > 1 week - Push 1.3-betas as-is.
> > > 2/3 weeks - Bug fix as people test it and push out rc's when
> > > we feel it's solid and stable.
> > > 4 weeks - Rename 1.x branch to 1.3.x.
> > > - Release 1.3.0 final and put 1.3.x immediately into
> > > maintenance mode.
> > > - Create 1.4.x branch from 1.3.0 tag.
> > > - Merge the model changes from trunk to 1.4.x.
> > > - Backport anything else from trunk to 1.4.x that's
> > > not JDK5-specific.
> > > 6 weeks - Push out 1.4-betas
> > > 7/8 weeks - Push out 1.4-rc's
> > > 9 weeks - Push out 1.4.0 final
> > > - Create 1.5.x branch from 1.4.0 tag.
> > > - Backport/add generics, covariance and other JDK 5 trunk
> > > features to the 1.5.x branch.
> > > - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> > > 14+ weeks - Release 1.5.0
> > >
> > > Suggestions to make this work:
> > > ------------------------------
> > > We won't backport from 1.4.x -> 1.3.x.
> > > We won't actively develop trunk.
> > > We will push 1.4 out very soon after 1.3, and encourage migration.
> > > We will have this in a public roadmap so people can see it coming.
> > >
> > > Notes on what you think is insanity, but actually isn't:
> > > --------------------------------------------------------
> > > We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
> > > 1.5.x and what's currently trunk). This may seem like madness to you,
> > > but I reckon it isn't:
> > >
> > > During 1.3 development, 2.x is low activity, 1.2.x negligible.
> > > During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> > > During 1.5 development, only 1.4.x will also be quite active.
> > >
> > > Once 1.5.0 is out, we can properly deprecate 2.0. People currently
> using
> > > it may not like being told to migrate to 1.5.x, but that shouldn't be
> > > too hard (much less hard than going from 1.3->2.0) and there shouldn't
> > > be too many of them. I guess that's the price you sometimes pay for
> > > using unreleased software. :-/
> > >
> > > I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> > > obviously encourage core developers and patchers to upgrade their
> sites
> > > to use 1.5.x, do active development on that, and therefore try to only
> > > ever backport from 1.5.x to 1.4.x, not forward-port the other way
> > around.
> > >
> > > If you think I'm smoking crack, the above is utterly unreasonable, you
> > > want to kick me out of the gang, or you have any better ideas or
> > > suggestions as to how to keep everyone happy, please shout now. :-)
> > >
> > > Best regards,
> > >
> > > Alastair
> > >
> > >
> >
> > --
> > View this message in context:
> > http://www.nabble.com/roadmap-tf3366743.html#a9372002
> > Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >
> >
>
Re: [Vote] roadmap
Posted by Johan Compagner <jc...@gmail.com>.
exactly my point.
On 3/8/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
>
> this feels too aggressive to me if 1.3 is to be released through
> apache. we
> want our first apache release to be the best it can be, not as fast as it
> can be because we've been promising it for a while. let's give ourselves
> a
> break and take the extra days it takes to backport model changes and
> important features to 1.3. if it takes even another month, it's still
> better because our story of what to use is more understandable... 1.4should
> really just be 1.3 + generics changes. that's very simple to explain.
>
> btw, let's not kick ourselves for working on 2.0 for a long time and
> falling
> behind our earlier promises of scheduling. unpredictable things have
> happened and these kinds of things happen even on the best projects. to
> our
> great credit, we've shown a willingness to evaluate our own work, suck it
> up
> and kill our darlings, as someone said. that's what makes something
> great.
> let's not push out a 1.3 that's less than it should be to meet a schedule
> we
> simply couldn't meet due to unforseen circumstances. i vote to slow down
> in
> spite of any scheduling pressure we may be feeling.
>
> jon
>
>
> igor.vaynberg wrote:
> >
> > pasted from almaw's email on @user
> >
> > -igor
> >
> > -------------------------- 8><
> > --------------------------------------------
> >
> > In my opinion we could, within the next:
> > -----------------------------------------
> > 1 week - Push 1.3-betas as-is.
> > 2/3 weeks - Bug fix as people test it and push out rc's when
> > we feel it's solid and stable.
> > 4 weeks - Rename 1.x branch to 1.3.x.
> > - Release 1.3.0 final and put 1.3.x immediately into
> > maintenance mode.
> > - Create 1.4.x branch from 1.3.0 tag.
> > - Merge the model changes from trunk to 1.4.x.
> > - Backport anything else from trunk to 1.4.x that's
> > not JDK5-specific.
> > 6 weeks - Push out 1.4-betas
> > 7/8 weeks - Push out 1.4-rc's
> > 9 weeks - Push out 1.4.0 final
> > - Create 1.5.x branch from 1.4.0 tag.
> > - Backport/add generics, covariance and other JDK 5 trunk
> > features to the 1.5.x branch.
> > - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> > 14+ weeks - Release 1.5.0
> >
> > Suggestions to make this work:
> > ------------------------------
> > We won't backport from 1.4.x -> 1.3.x.
> > We won't actively develop trunk.
> > We will push 1.4 out very soon after 1.3, and encourage migration.
> > We will have this in a public roadmap so people can see it coming.
> >
> > Notes on what you think is insanity, but actually isn't:
> > --------------------------------------------------------
> > We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
> > 1.5.x and what's currently trunk). This may seem like madness to you,
> > but I reckon it isn't:
> >
> > During 1.3 development, 2.x is low activity, 1.2.x negligible.
> > During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> > During 1.5 development, only 1.4.x will also be quite active.
> >
> > Once 1.5.0 is out, we can properly deprecate 2.0. People currently using
> > it may not like being told to migrate to 1.5.x, but that shouldn't be
> > too hard (much less hard than going from 1.3->2.0) and there shouldn't
> > be too many of them. I guess that's the price you sometimes pay for
> > using unreleased software. :-/
> >
> > I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> > obviously encourage core developers and patchers to upgrade their sites
> > to use 1.5.x, do active development on that, and therefore try to only
> > ever backport from 1.5.x to 1.4.x, not forward-port the other way
> around.
> >
> > If you think I'm smoking crack, the above is utterly unreasonable, you
> > want to kick me out of the gang, or you have any better ideas or
> > suggestions as to how to keep everyone happy, please shout now. :-)
> >
> > Best regards,
> >
> > Alastair
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/roadmap-tf3366743.html#a9372002
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: [Vote] roadmap
Posted by Jonathan Locke <jo...@gmail.com>.
this feels too aggressive to me if 1.3 is to be released through apache. we
want our first apache release to be the best it can be, not as fast as it
can be because we've been promising it for a while. let's give ourselves a
break and take the extra days it takes to backport model changes and
important features to 1.3. if it takes even another month, it's still
better because our story of what to use is more understandable... 1.4 should
really just be 1.3 + generics changes. that's very simple to explain.
btw, let's not kick ourselves for working on 2.0 for a long time and falling
behind our earlier promises of scheduling. unpredictable things have
happened and these kinds of things happen even on the best projects. to our
great credit, we've shown a willingness to evaluate our own work, suck it up
and kill our darlings, as someone said. that's what makes something great.
let's not push out a 1.3 that's less than it should be to meet a schedule we
simply couldn't meet due to unforseen circumstances. i vote to slow down in
spite of any scheduling pressure we may be feeling.
jon
igor.vaynberg wrote:
>
> pasted from almaw's email on @user
>
> -igor
>
> -------------------------- 8><
> --------------------------------------------
>
> In my opinion we could, within the next:
> -----------------------------------------
> 1 week - Push 1.3-betas as-is.
> 2/3 weeks - Bug fix as people test it and push out rc's when
> we feel it's solid and stable.
> 4 weeks - Rename 1.x branch to 1.3.x.
> - Release 1.3.0 final and put 1.3.x immediately into
> maintenance mode.
> - Create 1.4.x branch from 1.3.0 tag.
> - Merge the model changes from trunk to 1.4.x.
> - Backport anything else from trunk to 1.4.x that's
> not JDK5-specific.
> 6 weeks - Push out 1.4-betas
> 7/8 weeks - Push out 1.4-rc's
> 9 weeks - Push out 1.4.0 final
> - Create 1.5.x branch from 1.4.0 tag.
> - Backport/add generics, covariance and other JDK 5 trunk
> features to the 1.5.x branch.
> - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> 14+ weeks - Release 1.5.0
>
> Suggestions to make this work:
> ------------------------------
> We won't backport from 1.4.x -> 1.3.x.
> We won't actively develop trunk.
> We will push 1.4 out very soon after 1.3, and encourage migration.
> We will have this in a public roadmap so people can see it coming.
>
> Notes on what you think is insanity, but actually isn't:
> --------------------------------------------------------
> We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
> 1.5.x and what's currently trunk). This may seem like madness to you,
> but I reckon it isn't:
>
> During 1.3 development, 2.x is low activity, 1.2.x negligible.
> During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> During 1.5 development, only 1.4.x will also be quite active.
>
> Once 1.5.0 is out, we can properly deprecate 2.0. People currently using
> it may not like being told to migrate to 1.5.x, but that shouldn't be
> too hard (much less hard than going from 1.3->2.0) and there shouldn't
> be too many of them. I guess that's the price you sometimes pay for
> using unreleased software. :-/
>
> I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> obviously encourage core developers and patchers to upgrade their sites
> to use 1.5.x, do active development on that, and therefore try to only
> ever backport from 1.5.x to 1.4.x, not forward-port the other way around.
>
> If you think I'm smoking crack, the above is utterly unreasonable, you
> want to kick me out of the gang, or you have any better ideas or
> suggestions as to how to keep everyone happy, please shout now. :-)
>
> Best regards,
>
> Alastair
>
>
--
View this message in context: http://www.nabble.com/roadmap-tf3366743.html#a9372002
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: roadmap
Posted by Martijn Dashorst <ma...@gmail.com>.
On 3/8/07, Andrew Lombardi <an...@mysticcoders.com> wrote:
> But I would hope that 2.0
> continues to receive bugfixes on an as needed basis, or you risk
> losing your fanatics because they have nowhere to go.
+1
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
Re: roadmap
Posted by Andrew Lombardi <an...@mysticcoders.com>.
It would seem to me, that through this dropping of constructor
change, and abandoning the 2.0 trunk/ ... There needs to be a really
nice and easy path to changing to the 1.3 or 1.4 branch, whatever the
case may be, and it needs to be clear. I have a feeling the 2.0
users are those most under the Wicket reality distortion field, and
the biggest cheerleaders, so making sure they don't feel abandoned is
important.
From what I'm hearing, the model change is the biggest item on the
agenda, and second is Java5. It seems like 1.3 should have the model
change, and 1.4 should have Java5. But I would hope that 2.0
continues to receive bugfixes on an as needed basis, or you risk
losing your fanatics because they have nowhere to go.
Andrew
On Mar 8, 2007, at 9:59 AM, Eelco Hillenius wrote:
>> why put a beta out if a huge api break is coming??? i will change
>> my vote to
>> -1 on releasing 1.3beta if we decide to fold the model refactor
>> into it.
>
> I don't find that kind of power play to be very constructive,
> especially not because you are largely responsible for the 2.0
> controversy (after being the greatest advocate for the change in the
> first place, and now the greatest advocate of reverting it). It's
> simple, if you want dropping 2.0 to happen you have to go through some
> pain too. If 2.0 stays, the models don't have to go in 1.3.
>
> Eelco
Re: roadmap
Posted by Igor Vaynberg <ig...@gmail.com>.
On 3/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > first of all this has nothing to do with a "power play". it has to do
> with a
> > simple fact that betas are meant to be stable releases that users can
> > develop against without worrying much about us pulling stuff from under
> > them.
>
> Threatening to veto is power play.
it is not a threat. i am still allowed to vote any way i choose no?
> Also, I don't agree with your definition of beta being non-breaking.
> You are in fact contradicting most of your own behavior in the
> project.
really? point me to a place in code where i introduced an api change that
breaks all clients in a beta that we knew was coming before we release the
beta.
it is ok to break minor things. but if we know a big all-client breaking
change is coming we should hold off.
> from the list i gather there is a large number of users that are waiting
> for
> > a beta before they start upgrading their projects for the above reason.
>
> Not many oppose the model change so far though. It should be quite an
> easy change for most occasions really. I think you and Al are making
> it larger than it really is.
i dont think it is necessarily a big deal, but we should not make a release
if we know this is coming.
Don't underestimate the amount of work that goes into rewriting and
> checking half a book of code example, ALL the wicket-stuff projects I
> converted, MOST of the other wicket projects I converted. We can all
> feel the pain here, and it is great that at least we tried to come up
> with the best solution and worked hard on trying to realize it. But we
> also have to admit that this whole situation is pretty amateuristic,
> and is not something we should repeat in the future.
i dont think there is anything mateuristic about this. it is the way of
software development. sometimes you try things that take a long time to
realize were not that great.
> The fact that the rest of the team +1-ed on it, makes us all
> responsible yes. But +1 a proposal is something else than actively
> advocating it and I currently feel kind of had to be slapped back for
> giving my support in the past.
this is bullshit. you evaluated it didnt you? or did you give a blind +1
vote? so now i am pretty much blamed for trying to come up with solutions to
problems. thats great.
-igor
Eelco
>
Re: roadmap
Posted by Igor Vaynberg <ig...@gmail.com>.
<Upayavira> ivaynberg: pong
<ivaynberg> can we graduate without a final release?
<Upayavira> yes
<Upayavira> final release is about code quality, not about legal stuff
<ivaynberg> but we need a public one?
<Upayavira> no
<ivaynberg> so just any kind of release
<ivaynberg> and we are good to go?
<ivaynberg> just a bunch of jars for incubator folks to look at?
<Upayavira> A packaged tarball made available on people.apache.org
<Upayavira> that's all that is needed
<Upayavira> That is the basis of Felix graduating.
<ivaynberg> and none of the graduated projects have become vaporware in the
past? :)
<Upayavira> However, I must say, I think that Wicket _should_ do a proper
release
<ivaynberg> proper as in final or beta?
<Upayavira> It is a much more developed product than Felix
<Upayavira> beta is fine
<ivaynberg> ok
<Upayavira> one that'll get used by people
On 3/8/07, Johan Compagner <jc...@gmail.com> wrote:
>
> What mean public release? Beta or final?
>
>
>
> On 3/8/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > we will not graduate until we have a _public_ release, no?
> >
> > -igor
> >
> >
> > On 3/8/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > >
> > > I think we need to slow down the discussion. It is not going to help
> > > us and our users to keep on shouting at each other about api breaks
> > > and other things.
> > >
> > > Our priorities should now be:
> > > - GRADUATE! : get 1.3-incubating-beta1 released and vetted by the ipmc
> > > - discuss slowly the future of trunk and the roadmap for 1.3 without
> > > powerplays, finger pointing and such. Blame throwing will not help
> > > trunk, nor get us graduated.
> > >
> > > Until then, I suggest we release 1.3-incubating-beta1 to the ipmc
> > > (doesn't have to go to the general public!) to get our asses out of
> > > the incubator. In the mean time we can discuss whatever is needed to
> > > solve our current problem with trunk. We need to give the discussion
> > > at least another week to get more users involved and their investment
> > > in trunk visible.
> > >
> > > Until then, no things that we could regret should go into 1.3,
> > > including the model refactor.
> > >
> > > Martijn
> > >
> > > --
> > > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > > Join the wicket community at irc.freenode.net: ##wicket
> > > Wicket 1.2.5 will keep your server alive. Download Wicket now!
> > > http://wicketframework.org
> > >
> >
>
Re: roadmap
Posted by Johan Compagner <jc...@gmail.com>.
What mean public release? Beta or final?
On 3/8/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> we will not graduate until we have a _public_ release, no?
>
> -igor
>
>
> On 3/8/07, Martijn Dashorst <ma...@gmail.com> wrote:
> >
> > I think we need to slow down the discussion. It is not going to help
> > us and our users to keep on shouting at each other about api breaks
> > and other things.
> >
> > Our priorities should now be:
> > - GRADUATE! : get 1.3-incubating-beta1 released and vetted by the ipmc
> > - discuss slowly the future of trunk and the roadmap for 1.3 without
> > powerplays, finger pointing and such. Blame throwing will not help
> > trunk, nor get us graduated.
> >
> > Until then, I suggest we release 1.3-incubating-beta1 to the ipmc
> > (doesn't have to go to the general public!) to get our asses out of
> > the incubator. In the mean time we can discuss whatever is needed to
> > solve our current problem with trunk. We need to give the discussion
> > at least another week to get more users involved and their investment
> > in trunk visible.
> >
> > Until then, no things that we could regret should go into 1.3,
> > including the model refactor.
> >
> > Martijn
> >
> > --
> > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > Join the wicket community at irc.freenode.net: ##wicket
> > Wicket 1.2.5 will keep your server alive. Download Wicket now!
> > http://wicketframework.org
> >
>
Re: roadmap
Posted by Igor Vaynberg <ig...@gmail.com>.
we will not graduate until we have a _public_ release, no?
-igor
On 3/8/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> I think we need to slow down the discussion. It is not going to help
> us and our users to keep on shouting at each other about api breaks
> and other things.
>
> Our priorities should now be:
> - GRADUATE! : get 1.3-incubating-beta1 released and vetted by the ipmc
> - discuss slowly the future of trunk and the roadmap for 1.3 without
> powerplays, finger pointing and such. Blame throwing will not help
> trunk, nor get us graduated.
>
> Until then, I suggest we release 1.3-incubating-beta1 to the ipmc
> (doesn't have to go to the general public!) to get our asses out of
> the incubator. In the mean time we can discuss whatever is needed to
> solve our current problem with trunk. We need to give the discussion
> at least another week to get more users involved and their investment
> in trunk visible.
>
> Until then, no things that we could regret should go into 1.3,
> including the model refactor.
>
> Martijn
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.5 will keep your server alive. Download Wicket now!
> http://wicketframework.org
>
Re: roadmap
Posted by Ryan Sonnek <ry...@gmail.com>.
> But see, it is not relevant for the people who are on 2.0, as they are
> using those features *today*. They have code that compiles today and
> projects they are working on today. They are not working on 2.0 to end
> up with 1.4 or 1.5; the only time they would do that is when we decide
> to drop 2.0. You can imagine they don't want to rewrite the models and
> validators and generics only to put it in at *some* later time *if* we
> decide to put these features in.
I'm a user of wicket 2.0, and I'm not worried about changes "breaking"
my app. the only people using 2.0 for their apps are either building
the source directly, or pulling down maven snapshots. either way,
they've either gotten used to "bleeding" edge development, or they've
moved to a more stable version (1.3).
Before worrying so much about providing 2.0 users with a migration
path, make sure that 2.0 users even *need* it. I really don't think
there are that many people using 2.0. I'm not worried about these
changes "breaking" my app and I'm sure anyone using 2.0 today is very
plugged into the ever changing codebase.
Re: roadmap
Posted by Eelco Hillenius <ee...@gmail.com>.
> No, we need to make the case clear and really be sure we don't want to
> continue with the constructor change. Too much has been invested into
> that project to decide on a whim that we discontinue it. Therefore
> discuss it with respect to eachother and the codebase. Ensure our
> users are included into the discussion. Ensure we don't leave out
> users because they enjoy a skiing trip.
>
> I stress again: this can't be decided before the weekend. It shouldn't.
Yes, I agree. See my other email where I propose some time to let it sink in.
> > Like I said earlier, these things go hand in hand. You can't just say,
> > we're probably gonna ditch 2.0 without providing an alternative for
> > those people working on it. Don't forget *we* have been encouraging
> > people to use 2.0 for their long running projects, so arguments like
> > 'that's what you got working with beta software' just won't do imo.
>
> We can decide on the future of 2.0 without deciding what we will do
> with the features inside. That actually comes after the decision to
> discontinue trunk. We really need to separate these discussions.
> Otherwise both get diluted.
No we really really cannot separate those things. The only way I am
ever gonna +1 on reverting the constructor change is if I agree with
the transition path for the users who are currently depending on 2.0.
This is not an attempt to do my part of power play. I'm just stating
that it would be unacceptable to me to have an incomplete transition
path and that it is also unacceptable to me to not deliver that soon
once we decided.
> We will, if that causes a lot of trouble for people already building
> on 1.3. We haven't decided even that trunk is going to be
> discontinued. Therefore we don't need the model refactor in 1.3.
That's fine. I'm all for letting the decision about the model back
port being based on whether or not we are going forward with reverting
the constructor change.
> Also the change is controversial, at least with Igor and that is for
> me reason enough to regret putting it in (right) now.
Yes, but this is not a normal future issue as it is connected to
providing a proper (complete!) migration path in case we decide to
drop 2.0.
> No question on the technical merit of the model change, I just don't
> think we should decide *now* to include it already. The vote is to
> include *NOW*, and that I don't want. I might even not want it in 1.3
> final. But that is something I want to discuss after we decide what to
> do with trunk, because then it is clear that we need to actually
> provide a short migration path.
Like I stated above, it is not something to discuss after we decide on
the constructor change, but rather something to discuss as part of it.
> > I want a release first to give people enough stability to do the model
> > change when they are ready for it. I *don't* want the model change in
> > another branch (after giving it a good thought) as that other branch
> > won't happen as soon as it should. Just won't; we have 2.5 years of
> > experience with the framework to prove that.
>
> We also have a team that is different for the last half year than the
> 2 years before that. Different people, different circumstances.
Sure. But putting up branch 1.4 and putting 1.3 in maintenance mode
within 3 or 4 weeks after we decide is just not going to happen. Or do
you disagree with that?
> I also think that for people currently on trunk, having 1.4 or 1.5
> with generics support will be sooner avaiable than continue trunk
> development at its current speed. If we decide to only do (for
> example) the model change and generics, I expect us to keep to it.
But see, it is not relevant for the people who are on 2.0, as they are
using those features *today*. They have code that compiles today and
projects they are working on today. They are not working on 2.0 to end
up with 1.4 or 1.5; the only time they would do that is when we decide
to drop 2.0. You can imagine they don't want to rewrite the models and
validators and generics only to put it in at *some* later time *if* we
decide to put these features in.
> But the generics in themselves are controversial and may need some extra
> development to make them really rock.
I backtrack on the earlier discussion I started. I'm afraid it's all
or nothing with those generics, so give or take a few tweaks, the way
it works in 2.0 would probably be pretty the way it would end up
working for any branch.
> So again, I stress: slow down this discussion, make sure we get our
> heads clear and get a plan together. Not this frenzy of roadmaps,
> votes and other stuff to make a hot headed discussion. First get
> 1.3-incubating through the ipmc, the rest can be discussed calmly with
> respect to each others positions.
>
> Martijn
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.5 will keep your server alive. Download Wicket now!
> http://wicketframework.org
>
Re: roadmap
Posted by Martijn Dashorst <ma...@gmail.com>.
On 3/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > Our priorities should now be:
> > - GRADUATE! : get 1.3-incubating-beta1 released and vetted by the ipmc
>
> Why is graduation suddenly the biggest priority now? For me finishing
> Wicket in action is a much larger priority to be honest, and getting
> rid of two difficult to maintain branches would be a bigger priority
> as well.
For me personally WIA is important as well, but we won't be shipping a
(final) release while inside the incubator. To get *any* release,
including either 1.3 or 2.0 (if not voted down) we need to leave the
incubator. This will be the best for the book as well, we need to
increase downloads to increase sales remember? Graduate -> release
And for the project I think graduating is very important. Focussing on
that, while discussing a roadmap in the background, without rushing
it, is what I think is best for the project.
> > - discuss slowly the future of trunk and the roadmap for 1.3 without
> > powerplays, finger pointing and such. Blame throwing will not help
> > trunk, nor get us graduated.
>
> I'm sorry, but it looked to me some blame throwing was in place to get
> the gravity of the discussion across. IF we decide to ditch 2.0, it's
> not going to be a free ride. We would have something to fix, and yes
> FAST to not alienate the users working on that.
No, we need to make the case clear and really be sure we don't want to
continue with the constructor change. Too much has been invested into
that project to decide on a whim that we discontinue it. Therefore
discuss it with respect to eachother and the codebase. Ensure our
users are included into the discussion. Ensure we don't leave out
users because they enjoy a skiing trip.
I stress again: this can't be decided before the weekend. It shouldn't.
> Like I said earlier, these things go hand in hand. You can't just say,
> we're probably gonna ditch 2.0 without providing an alternative for
> those people working on it. Don't forget *we* have been encouraging
> people to use 2.0 for their long running projects, so arguments like
> 'that's what you got working with beta software' just won't do imo.
We can decide on the future of 2.0 without deciding what we will do
with the features inside. That actually comes after the decision to
discontinue trunk. We really need to separate these discussions.
Otherwise both get diluted.
> > Until then, no things that we could regret should go into 1.3,
> > including the model refactor.
>
> Well this is something I don't get: why would we regret it? We won't.
We will, if that causes a lot of trouble for people already building
on 1.3. We haven't decided even that trunk is going to be
discontinued. Therefore we don't need the model refactor in 1.3.
Also the change is controversial, at least with Igor and that is for
me reason enough to regret putting it in (right) now.
> The models got much better, the upgrade possibility is as far as I
> know complete and in most cases as easy as removing that parameter.
No question on the technical merit of the model change, I just don't
think we should decide *now* to include it already. The vote is to
include *NOW*, and that I don't want. I might even not want it in 1.3
final. But that is something I want to discuss after we decide what to
do with trunk, because then it is clear that we need to actually
provide a short migration path.
> I want a release first to give people enough stability to do the model
> change when they are ready for it. I *don't* want the model change in
> another branch (after giving it a good thought) as that other branch
> won't happen as soon as it should. Just won't; we have 2.5 years of
> experience with the framework to prove that.
We also have a team that is different for the last half year than the
2 years before that. Different people, different circumstances.
I also think that for people currently on trunk, having 1.4 or 1.5
with generics support will be sooner avaiable than continue trunk
development at its current speed. If we decide to only do (for
example) the model change and generics, I expect us to keep to it. But
the generics in themselves are controversial and may need some extra
development to make them really rock.
So again, I stress: slow down this discussion, make sure we get our
heads clear and get a plan together. Not this frenzy of roadmaps,
votes and other stuff to make a hot headed discussion. First get
1.3-incubating through the ipmc, the rest can be discussed calmly with
respect to each others positions.
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
Re: roadmap
Posted by Eelco Hillenius <ee...@gmail.com>.
> Our priorities should now be:
> - GRADUATE! : get 1.3-incubating-beta1 released and vetted by the ipmc
Why is graduation suddenly the biggest priority now? For me finishing
Wicket in action is a much larger priority to be honest, and getting
rid of two difficult to maintain branches would be a bigger priority
as well.
> - discuss slowly the future of trunk and the roadmap for 1.3 without
> powerplays, finger pointing and such. Blame throwing will not help
> trunk, nor get us graduated.
I'm sorry, but it looked to me some blame throwing was in place to get
the gravity of the discussion across. IF we decide to ditch 2.0, it's
not going to be a free ride. We would have something to fix, and yes
FAST to not alienate the users working on that.
> Until then, I suggest we release 1.3-incubating-beta1 to the ipmc
> (doesn't have to go to the general public!) to get our asses out of
> the incubator. In the mean time we can discuss whatever is needed to
> solve our current problem with trunk. We need to give the discussion
> at least another week to get more users involved and their investment
> in trunk visible.
Like I said earlier, these things go hand in hand. You can't just say,
we're probably gonna ditch 2.0 without providing an alternative for
those people working on it. Don't forget *we* have been encouraging
people to use 2.0 for their long running projects, so arguments like
'that's what you got working with beta software' just won't do imo.
> Until then, no things that we could regret should go into 1.3,
> including the model refactor.
Well this is something I don't get: why would we regret it? We won't.
The models got much better, the upgrade possibility is as far as I
know complete and in most cases as easy as removing that parameter.
I want a release first to give people enough stability to do the model
change when they are ready for it. I *don't* want the model change in
another branch (after giving it a good thought) as that other branch
won't happen as soon as it should. Just won't; we have 2.5 years of
experience with the framework to prove that.
Eelco
Re: roadmap
Posted by Martijn Dashorst <ma...@gmail.com>.
I think we need to slow down the discussion. It is not going to help
us and our users to keep on shouting at each other about api breaks
and other things.
Our priorities should now be:
- GRADUATE! : get 1.3-incubating-beta1 released and vetted by the ipmc
- discuss slowly the future of trunk and the roadmap for 1.3 without
powerplays, finger pointing and such. Blame throwing will not help
trunk, nor get us graduated.
Until then, I suggest we release 1.3-incubating-beta1 to the ipmc
(doesn't have to go to the general public!) to get our asses out of
the incubator. In the mean time we can discuss whatever is needed to
solve our current problem with trunk. We need to give the discussion
at least another week to get more users involved and their investment
in trunk visible.
Until then, no things that we could regret should go into 1.3,
including the model refactor.
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
Re: roadmap
Posted by Johan Compagner <jc...@gmail.com>.
> I think we should have a regular vote on this. One way or another, we
> need to come to a conclusion. I wish we could just sit somewhere, have a
> beer and discuss this live :)
ApacheCon!
But i guess thats a bit to late for the most discussions we have here :(
johan
Re: roadmap
Posted by Johan Compagner <jc...@gmail.com>.
Just buy everybody a beer on queens day (or night)
> Ok, fair enough. Sorry for being rude on that Igor and others. I agree
> that wasn't a helpful thing of me to do.
>
>
Re: roadmap
Posted by Eelco Hillenius <ee...@gmail.com>.
> The constructor change really seemed to fix the issues we had. I
> remember really liking the idea. And I also liked using it. But the
> truth is that it lacks certain flexibility for complex situations and
> this is not something that could have been easily predicted. I don't
> think that blaming anyone for supporting/advocating the change is the
> way to go.
>
> And I don't even thing that it is amateurish. You really have to try
> some things and get burned, there's no other way. We are not
> implementing a JSR. We need to experiment. And this one doesn't really
> worked better that what we had before. Which doesn't mean that it's
> completely wrong. It's just that the pros don't outweight the cons. But
> we needed to try it first to find that out.
Ok, fair enough. Sorry for being rude on that Igor and others. I agree
that wasn't a helpful thing of me to do.
> I think we should have a regular vote on this. One way or another, we
> need to come to a conclusion. I wish we could just sit somewhere, have a
> beer and discuss this live :)
Yes, that would be nice :)
Eelco
Re: roadmap
Posted by Matej Knopp <ma...@knopp.sk>.
The constructor change really seemed to fix the issues we had. I
remember really liking the idea. And I also liked using it. But the
truth is that it lacks certain flexibility for complex situations and
this is not something that could have been easily predicted. I don't
think that blaming anyone for supporting/advocating the change is the
way to go.
And I don't even thing that it is amateurish. You really have to try
some things and get burned, there's no other way. We are not
implementing a JSR. We need to experiment. And this one doesn't really
worked better that what we had before. Which doesn't mean that it's
completely wrong. It's just that the pros don't outweight the cons. But
we needed to try it first to find that out.
I think right now it's pretty sure that 2.0 is not the way to go. So
what we need to decide is whether to backport the models to 1.3 or not.
My personal opinion is - let's do that. I don't really think it's gonna
be that hard to convert old models to new. Simple models will just get
removed the component argument, property and compound model will just
become inner subclasses. Is this really such a big deal?
I think we should have a regular vote on this. One way or another, we
need to come to a conclusion. I wish we could just sit somewhere, have a
beer and discuss this live :)
-Matej
Eelco Hillenius wrote:
>> first of all this has nothing to do with a "power play". it has to do
>> with a
>> simple fact that betas are meant to be stable releases that users can
>> develop against without worrying much about us pulling stuff from under
>> them.
>
> Threatening to veto is power play.
>
> Also, I don't agree with your definition of beta being non-breaking.
> You are in fact contradicting most of your own behavior in the
> project.
>
>> from the list i gather there is a large number of users that are
>> waiting for
>> a beta before they start upgrading their projects for the above reason.
>
> Not many oppose the model change so far though. It should be quite an
> easy change for most occasions really. I think you and Al are making
> it larger than it really is.
>
>> second of all, yes i was the advocate. i was trying to find a way to
>> solve
>> the problems everyone were complaining about. i found away, i proposed
>> it,
>> we had a discussion and a vote. we all voted +1. now that i had a
>> chance to
>> extensively use the api i dont think it was worth it and so i started the
>> discussion again. it will take another vote where everyone votes to
>> resolve
>> this. i have two large projects on trunk, so i think i am affected
>> more then
>> others by this rollback with regards to hours of work. so take that back.
>
> Don't underestimate the amount of work that goes into rewriting and
> checking half a book of code example, ALL the wicket-stuff projects I
> converted, MOST of the other wicket projects I converted. We can all
> feel the pain here, and it is great that at least we tried to come up
> with the best solution and worked hard on trying to realize it. But we
> also have to admit that this whole situation is pretty amateuristic,
> and is not something we should repeat in the future.
>
> The fact that the rest of the team +1-ed on it, makes us all
> responsible yes. But +1 a proposal is something else than actively
> advocating it and I currently feel kind of had to be slapped back for
> giving my support in the past.
>
> Eelco
>
Re: roadmap
Posted by Eelco Hillenius <ee...@gmail.com>.
> first of all this has nothing to do with a "power play". it has to do with a
> simple fact that betas are meant to be stable releases that users can
> develop against without worrying much about us pulling stuff from under
> them.
Threatening to veto is power play.
Also, I don't agree with your definition of beta being non-breaking.
You are in fact contradicting most of your own behavior in the
project.
> from the list i gather there is a large number of users that are waiting for
> a beta before they start upgrading their projects for the above reason.
Not many oppose the model change so far though. It should be quite an
easy change for most occasions really. I think you and Al are making
it larger than it really is.
> second of all, yes i was the advocate. i was trying to find a way to solve
> the problems everyone were complaining about. i found away, i proposed it,
> we had a discussion and a vote. we all voted +1. now that i had a chance to
> extensively use the api i dont think it was worth it and so i started the
> discussion again. it will take another vote where everyone votes to resolve
> this. i have two large projects on trunk, so i think i am affected more then
> others by this rollback with regards to hours of work. so take that back.
Don't underestimate the amount of work that goes into rewriting and
checking half a book of code example, ALL the wicket-stuff projects I
converted, MOST of the other wicket projects I converted. We can all
feel the pain here, and it is great that at least we tried to come up
with the best solution and worked hard on trying to realize it. But we
also have to admit that this whole situation is pretty amateuristic,
and is not something we should repeat in the future.
The fact that the rest of the team +1-ed on it, makes us all
responsible yes. But +1 a proposal is something else than actively
advocating it and I currently feel kind of had to be slapped back for
giving my support in the past.
Eelco
Re: roadmap
Posted by Igor Vaynberg <ig...@gmail.com>.
first of all this has nothing to do with a "power play". it has to do with a
simple fact that betas are meant to be stable releases that users can
develop against without worrying much about us pulling stuff from under
them.
from the list i gather there is a large number of users that are waiting for
a beta before they start upgrading their projects for the above reason.
second of all, yes i was the advocate. i was trying to find a way to solve
the problems everyone were complaining about. i found away, i proposed it,
we had a discussion and a vote. we all voted +1. now that i had a chance to
extensively use the api i dont think it was worth it and so i started the
discussion again. it will take another vote where everyone votes to resolve
this. i have two large projects on trunk, so i think i am affected more then
others by this rollback with regards to hours of work. so take that back.
-igor
On 3/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > why put a beta out if a huge api break is coming??? i will change my
> vote to
> > -1 on releasing 1.3beta if we decide to fold the model refactor into it.
>
> I don't find that kind of power play to be very constructive,
> especially not because you are largely responsible for the 2.0
> controversy (after being the greatest advocate for the change in the
> first place, and now the greatest advocate of reverting it). It's
> simple, if you want dropping 2.0 to happen you have to go through some
> pain too. If 2.0 stays, the models don't have to go in 1.3.
>
> Eelco
>
Re: roadmap
Posted by Eelco Hillenius <ee...@gmail.com>.
> why put a beta out if a huge api break is coming??? i will change my vote to
> -1 on releasing 1.3beta if we decide to fold the model refactor into it.
I don't find that kind of power play to be very constructive,
especially not because you are largely responsible for the 2.0
controversy (after being the greatest advocate for the change in the
first place, and now the greatest advocate of reverting it). It's
simple, if you want dropping 2.0 to happen you have to go through some
pain too. If 2.0 stays, the models don't have to go in 1.3.
Eelco
Re: roadmap
Posted by Igor Vaynberg <ig...@gmail.com>.
why put a beta out if a huge api break is coming??? i will change my vote to
-1 on releasing 1.3beta if we decide to fold the model refactor into it.
-igor
On 3/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > Yes, that's right. I'm just splitting 1.3 up into two smaller chunks in
> > an attempt to make things happen sooner and be more manageable.
>
> I'd much rather do exactly that: split 1.3 into smaller chunks. Put a
> beta out this weekend so that people can take a brake from upgrading,
> but put the model change in to get it over with. The new models have
> been tested well and for most users this should be quite an easy
> upgrade anyway.
>
> > If we put the model refactor into 1.3 then I reckon it will be ready for
> > release around about the same time that 1.4 would otherwise be, or
> > possibly even later.
>
> I'm not concerned at all about when we actually release 1.3. I'm
> concerned about when the feature set will be available in SVN for the
> users that are on 2.0 now, including myself. We can't just put them on
> hold for months, and we want less branches, not more.
>
> Eelco
>
Re: roadmap
Posted by Eelco Hillenius <ee...@gmail.com>.
> Yes, that's right. I'm just splitting 1.3 up into two smaller chunks in
> an attempt to make things happen sooner and be more manageable.
I'd much rather do exactly that: split 1.3 into smaller chunks. Put a
beta out this weekend so that people can take a brake from upgrading,
but put the model change in to get it over with. The new models have
been tested well and for most users this should be quite an easy
upgrade anyway.
> If we put the model refactor into 1.3 then I reckon it will be ready for
> release around about the same time that 1.4 would otherwise be, or
> possibly even later.
I'm not concerned at all about when we actually release 1.3. I'm
concerned about when the feature set will be available in SVN for the
users that are on 2.0 now, including myself. We can't just put them on
hold for months, and we want less branches, not more.
Eelco
Re: roadmap
Posted by Johan Compagner <jc...@gmail.com>.
See my other mail about most points you make that i think completely the
opposite about
But when are we making the namespace change???
1.4? or 1.5?
johan
On 3/8/07, Al Maw <wi...@almaw.com> wrote:
>
> Johan Compagner wrote:
> > i really hate that roadmap, really i do.
> [...]
>
> > So you really want quickly 1.4 after 1.3 and i guess 1.3 is completely
> in
> > maintenance mode pretty much directly
> > because if we start working on 1.5 you really don't want 1.3 anymore
>
> Absolutely. As soon as we've pushed 1.4 out, full steam ahead on 1.5,
> with 1.3 very much in bug-fix-only and encouraging people to switch to
> 1.4 ASAP.
>
> > That means that people that all do 1.3 stuff now are going to 1.4 anyway
> > (especially because it is also not java5 yet again)
>
> Yes. But they get to do a really complicated Model refactor over the
> course of a few weeks, rather than Right This Second. If we have an
> agreed roadmap, then the users will even see this coming and be able to
> make their own mind up as to whether they want to split their upgrade
> effort into two chunks, or just wait a little longer 'til 1.4 comes out.
>
> > Releasing so quickly is in my eyes a bad thing. And i really don't want
> to
> > release as much under the incubating flag
> > (i sort of already don't want to do that for 1.3!! but i can live with
> that
> > if we really really have to)
>
> Another fly in the ointment is that we will need to move to the
> org.apache.wicket namespace at some point. If we have both JDK 1.4 and
> JDK 1.5 branches that we're trying to keep in sync, merging will be
> slightly more annoying due to the import mismatch, although I guess
> that's fairly minor.
>
> The main point here is that we probably won't graduate from incubation
> until we switch to this namespace. Would people be happy to do this for
> 1.3? It's a pretty trivial update for people - just global search and
> replace on "import wicket." to "import org.apache.wicket." (with the
> exception of things in wicket-stuff like the datepicker). We should
> maybe start a vote on this. We will certainly have to do it in 1.4, no
> matter what that looks like.
>
> > so i am -1 on this release cycle.
> > what you call 1.3 and 1.4 should be in my eyes 1.3 and why you call 1.5is
> > in my eyes 1.4.
>
> Yes, that's right. I'm just splitting 1.3 up into two smaller chunks in
> an attempt to make things happen sooner and be more manageable. If we
> put the model refactor into 1.3 then I reckon it will be ready for
> release around about the same time that 1.4 would otherwise be, or
> possibly even later.
>
> You see, this split would allow us to parallelise the two things that I
> can see taking a while; getting an Apache-grade release out, and having
> users migrate to the new Model code.
>
> If we don't parallelise it, I think we'll end up doing things in a more
> sequential fashion and the whole process will take longer. Once we have
> a good solid release process, rolling out a 1.4 will be negligible
> effort. It therefore wouldn't surprise me if it took longer to do a 1.3
> with the model change in it than to get to a 1.4 under this proposal.
>
> Of course, if you're happy to delay rolling out a 1.3 beta for yet
> another month, then that's fine. I can tell you that I'll be busy
> porting my models for a week or so and not testing things/writing build
> code if we push the refactor in right now. :(
>
> > Give people a big chunk and let that sink in for quite a while. Dont go
> > releasing like a mad man.
>
> I'm not convinced. Release early, release often.
>
> BTW, I'm on holiday the week from 19th -> 26th, so won't be around to
> help with releases and things during that time.
>
> Al
>
Re: roadmap
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Al Maw:
> Another fly in the ointment is that we will need to move to the
> org.apache.wicket namespace at some point. If we have both JDK
> 1.4 and JDK 1.5 branches that we're trying to keep in sync,
> merging will be slightly more annoying due to the import
> mismatch, although I guess that's fairly minor.
>
> The main point here is that we probably won't graduate from
> incubation until we switch to this namespace. Would people be
> happy to do this for 1.3? It's a pretty trivial update for
> people - just global search and replace on "import wicket." to
> "import org.apache.wicket." (with the exception of things in
> wicket-stuff like the datepicker). We should maybe start a vote
> on this. We will certainly have to do it in 1.4, no matter what
> that looks like.
I wouldn't switch to the new namespace until all features from
trunk are backported to 1.x, as merging would be much more
difficult, it's already a mess right now.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: roadmap
Posted by Al Maw <wi...@almaw.com>.
Johan Compagner wrote:
> i really hate that roadmap, really i do.
[...]
> So you really want quickly 1.4 after 1.3 and i guess 1.3 is completely in
> maintenance mode pretty much directly
> because if we start working on 1.5 you really don't want 1.3 anymore
Absolutely. As soon as we've pushed 1.4 out, full steam ahead on 1.5,
with 1.3 very much in bug-fix-only and encouraging people to switch to
1.4 ASAP.
> That means that people that all do 1.3 stuff now are going to 1.4 anyway
> (especially because it is also not java5 yet again)
Yes. But they get to do a really complicated Model refactor over the
course of a few weeks, rather than Right This Second. If we have an
agreed roadmap, then the users will even see this coming and be able to
make their own mind up as to whether they want to split their upgrade
effort into two chunks, or just wait a little longer 'til 1.4 comes out.
> Releasing so quickly is in my eyes a bad thing. And i really don't want to
> release as much under the incubating flag
> (i sort of already don't want to do that for 1.3!! but i can live with that
> if we really really have to)
Another fly in the ointment is that we will need to move to the
org.apache.wicket namespace at some point. If we have both JDK 1.4 and
JDK 1.5 branches that we're trying to keep in sync, merging will be
slightly more annoying due to the import mismatch, although I guess
that's fairly minor.
The main point here is that we probably won't graduate from incubation
until we switch to this namespace. Would people be happy to do this for
1.3? It's a pretty trivial update for people - just global search and
replace on "import wicket." to "import org.apache.wicket." (with the
exception of things in wicket-stuff like the datepicker). We should
maybe start a vote on this. We will certainly have to do it in 1.4, no
matter what that looks like.
> so i am -1 on this release cycle.
> what you call 1.3 and 1.4 should be in my eyes 1.3 and why you call 1.5 is
> in my eyes 1.4.
Yes, that's right. I'm just splitting 1.3 up into two smaller chunks in
an attempt to make things happen sooner and be more manageable. If we
put the model refactor into 1.3 then I reckon it will be ready for
release around about the same time that 1.4 would otherwise be, or
possibly even later.
You see, this split would allow us to parallelise the two things that I
can see taking a while; getting an Apache-grade release out, and having
users migrate to the new Model code.
If we don't parallelise it, I think we'll end up doing things in a more
sequential fashion and the whole process will take longer. Once we have
a good solid release process, rolling out a 1.4 will be negligible
effort. It therefore wouldn't surprise me if it took longer to do a 1.3
with the model change in it than to get to a 1.4 under this proposal.
Of course, if you're happy to delay rolling out a 1.3 beta for yet
another month, then that's fine. I can tell you that I'll be busy
porting my models for a week or so and not testing things/writing build
code if we push the refactor in right now. :(
> Give people a big chunk and let that sink in for quite a while. Dont go
> releasing like a mad man.
I'm not convinced. Release early, release often.
BTW, I'm on holiday the week from 19th -> 26th, so won't be around to
help with releases and things during that time.
Al
Re: roadmap
Posted by Johan Compagner <jc...@gmail.com>.
oeps sorry didn't see this thread yet so here is it again:
i really hate that roadmap, really i do.
So you really want quickly 1.4 after 1.3 and i guess 1.3 is completely in
maintenance mode pretty much directly
because if we start working on 1.5 you really don't want 1.3 anymore
That means that people that all do 1.3 stuff now are going to 1.4 anyway
(especially because it is also not java5 yet again)
Releasing so quickly is in my eyes a bad thing. And i really don't want to
release as much under the incubating flag
(i sort of already don't want to do that for 1.3!! but i can live with that
if we really really have to)
so i am -1 on this release cycle.
what you call 1.3 and 1.4 should be in my eyes 1.3 and why you call 1.5 is
in my eyes 1.4.
Give people a big chunk and let that sink in for quite a while. Dont go
releasing like a mad man.
johan- Show quoted text -
Re: roadmap
Posted by Eelco Hillenius <ee...@gmail.com>.
> well yeah. write the text now, and the code examples later. or is that too
> unmanageable?
That's funny, really. :)
> but according to the roadmap we are releasing 1.4 fairly soon. can you put
> off the chapters that are affected by this?
To some degree, for a couple of weeks at most.
> we do need to work around you to some degree because the book is an
> important asset, so you need to tell us what will absolutely not work for
> you and what you can live with.
I/ we can live with a week or 3/ 4, but that would be absolutely the
max before we get in serious trouble. But I'll let Martijn chip in
when he wakes up.
Eelco
Re: roadmap
Posted by Igor Vaynberg <ig...@gmail.com>.
well yeah. write the text now, and the code examples later. or is that too
unmanageable?
but according to the roadmap we are releasing 1.4 fairly soon. can you put
off the chapters that are affected by this?
we do need to work around you to some degree because the book is an
important asset, so you need to tell us what will absolutely not work for
you and what you can live with.
-igor
On 3/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> Right, how are we gonna compile that? Doesn't work like that. We have
> a source tree in sync with the examples.
>
> Eelco
>
>
> On 3/7/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > so write the models against 2.0. they will be exactly the same in
> > 1.4branch. code examples i guess you can leave for later?
> >
> > -igor
> >
> >
> > On 3/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > A very big problem for Martijn and me is actually that we can't go on
> > > with writing until 1.4 is created. Models are everywhere in the book,
> > > including a separate chapter, and they are based on the 2.0 models
> > > currently. Martijn and me would have to decide on whether to target
> > > 1.4 or 1.5 but it would be either of them. Freezing the writing for a
> > > few weeks is really unacceptable for us. I understand your problems of
> > > accepting the model change for 1.3, but if it doesn't get in there -
> > > which is fine - Martijn and me need that 1.4 branch fast.
> > >
> > > Eelco
> > >
> > >
> > > On 3/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > This sounds good to me. The main point of critique I can think of is
> > > > that so far we haven't be able to do releases very fast. So in that
> > > > sense, the time schedule is probably very unrealistic. However,
> there
> > > > is nothing I would like more then us to be able to actually *do*
> > > > releases fast, so if this is another carrot on a stick to make
> *that*
> > > > happen, I'm all for it.
> > > >
> > > > Eelco
> > > >
> > > >
> > > > On 3/7/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > > pasted from almaw's email on @user
> > > > >
> > > > > -igor
> > > > >
> > > > > -------------------------- 8><
> > > --------------------------------------------
> > > > >
> > > > > In my opinion we could, within the next:
> > > > > -----------------------------------------
> > > > > 1 week - Push 1.3-betas as-is.
> > > > > 2/3 weeks - Bug fix as people test it and push out rc's when
> > > > > we feel it's solid and stable.
> > > > > 4 weeks - Rename 1.x branch to 1.3.x.
> > > > > - Release 1.3.0 final and put 1.3.x immediately into
> > > > > maintenance mode.
> > > > > - Create 1.4.x branch from 1.3.0 tag.
> > > > > - Merge the model changes from trunk to 1.4.x.
> > > > > - Backport anything else from trunk to 1.4.x that's
> > > > > not JDK5-specific.
> > > > > 6 weeks - Push out 1.4-betas
> > > > > 7/8 weeks - Push out 1.4-rc's
> > > > > 9 weeks - Push out 1.4.0 final
> > > > > - Create 1.5.x branch from 1.4.0 tag.
> > > > > - Backport/add generics, covariance and other JDK 5
> trunk
> > > > > features to the 1.5.x branch.
> > > > > - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> > > > > 14+ weeks - Release 1.5.0
> > > > >
> > > > > Suggestions to make this work:
> > > > > ------------------------------
> > > > > We won't backport from 1.4.x -> 1.3.x.
> > > > > We won't actively develop trunk.
> > > > > We will push 1.4 out very soon after 1.3, and encourage migration.
> > > > > We will have this in a public roadmap so people can see it coming.
> > > > >
> > > > > Notes on what you think is insanity, but actually isn't:
> > > > > --------------------------------------------------------
> > > > > We will of course end up with five(!) branches (1.2.x, 1.3.x,
> 1.4.x,
> > > > > 1.5.x and what's currently trunk). This may seem like madness to
> you,
> > > > > but I reckon it isn't:
> > > > >
> > > > > During 1.3 development, 2.x is low activity, 1.2.x negligible.
> > > > > During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> > > > > During 1.5 development, only 1.4.x will also be quite active.
> > > > >
> > > > > Once 1.5.0 is out, we can properly deprecate 2.0. People currently
> > > using
> > > > > it may not like being told to migrate to 1.5.x, but that shouldn't
> be
> > > > > too hard (much less hard than going from 1.3->2.0) and there
> shouldn't
> > > > > be too many of them. I guess that's the price you sometimes pay
> for
> > > > > using unreleased software. :-/
> > > > >
> > > > > I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> > > > > obviously encourage core developers and patchers to upgrade their
> > > sites
> > > > > to use 1.5.x, do active development on that, and therefore try to
> only
> > > > > ever backport from 1.5.x to 1.4.x, not forward-port the other way
> > > around.
> > > > >
> > > > > If you think I'm smoking crack, the above is utterly unreasonable,
> you
> > > > > want to kick me out of the gang, or you have any better ideas or
> > > > > suggestions as to how to keep everyone happy, please shout now.
> :-)
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Alastair
> > > > >
> > > >
> > >
> >
>
Re: roadmap
Posted by Eelco Hillenius <ee...@gmail.com>.
Right, how are we gonna compile that? Doesn't work like that. We have
a source tree in sync with the examples.
Eelco
On 3/7/07, Igor Vaynberg <ig...@gmail.com> wrote:
> so write the models against 2.0. they will be exactly the same in
> 1.4branch. code examples i guess you can leave for later?
>
> -igor
>
>
> On 3/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > A very big problem for Martijn and me is actually that we can't go on
> > with writing until 1.4 is created. Models are everywhere in the book,
> > including a separate chapter, and they are based on the 2.0 models
> > currently. Martijn and me would have to decide on whether to target
> > 1.4 or 1.5 but it would be either of them. Freezing the writing for a
> > few weeks is really unacceptable for us. I understand your problems of
> > accepting the model change for 1.3, but if it doesn't get in there -
> > which is fine - Martijn and me need that 1.4 branch fast.
> >
> > Eelco
> >
> >
> > On 3/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > This sounds good to me. The main point of critique I can think of is
> > > that so far we haven't be able to do releases very fast. So in that
> > > sense, the time schedule is probably very unrealistic. However, there
> > > is nothing I would like more then us to be able to actually *do*
> > > releases fast, so if this is another carrot on a stick to make *that*
> > > happen, I'm all for it.
> > >
> > > Eelco
> > >
> > >
> > > On 3/7/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > pasted from almaw's email on @user
> > > >
> > > > -igor
> > > >
> > > > -------------------------- 8><
> > --------------------------------------------
> > > >
> > > > In my opinion we could, within the next:
> > > > -----------------------------------------
> > > > 1 week - Push 1.3-betas as-is.
> > > > 2/3 weeks - Bug fix as people test it and push out rc's when
> > > > we feel it's solid and stable.
> > > > 4 weeks - Rename 1.x branch to 1.3.x.
> > > > - Release 1.3.0 final and put 1.3.x immediately into
> > > > maintenance mode.
> > > > - Create 1.4.x branch from 1.3.0 tag.
> > > > - Merge the model changes from trunk to 1.4.x.
> > > > - Backport anything else from trunk to 1.4.x that's
> > > > not JDK5-specific.
> > > > 6 weeks - Push out 1.4-betas
> > > > 7/8 weeks - Push out 1.4-rc's
> > > > 9 weeks - Push out 1.4.0 final
> > > > - Create 1.5.x branch from 1.4.0 tag.
> > > > - Backport/add generics, covariance and other JDK 5 trunk
> > > > features to the 1.5.x branch.
> > > > - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> > > > 14+ weeks - Release 1.5.0
> > > >
> > > > Suggestions to make this work:
> > > > ------------------------------
> > > > We won't backport from 1.4.x -> 1.3.x.
> > > > We won't actively develop trunk.
> > > > We will push 1.4 out very soon after 1.3, and encourage migration.
> > > > We will have this in a public roadmap so people can see it coming.
> > > >
> > > > Notes on what you think is insanity, but actually isn't:
> > > > --------------------------------------------------------
> > > > We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
> > > > 1.5.x and what's currently trunk). This may seem like madness to you,
> > > > but I reckon it isn't:
> > > >
> > > > During 1.3 development, 2.x is low activity, 1.2.x negligible.
> > > > During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> > > > During 1.5 development, only 1.4.x will also be quite active.
> > > >
> > > > Once 1.5.0 is out, we can properly deprecate 2.0. People currently
> > using
> > > > it may not like being told to migrate to 1.5.x, but that shouldn't be
> > > > too hard (much less hard than going from 1.3->2.0) and there shouldn't
> > > > be too many of them. I guess that's the price you sometimes pay for
> > > > using unreleased software. :-/
> > > >
> > > > I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> > > > obviously encourage core developers and patchers to upgrade their
> > sites
> > > > to use 1.5.x, do active development on that, and therefore try to only
> > > > ever backport from 1.5.x to 1.4.x, not forward-port the other way
> > around.
> > > >
> > > > If you think I'm smoking crack, the above is utterly unreasonable, you
> > > > want to kick me out of the gang, or you have any better ideas or
> > > > suggestions as to how to keep everyone happy, please shout now. :-)
> > > >
> > > > Best regards,
> > > >
> > > > Alastair
> > > >
> > >
> >
>
Re: roadmap
Posted by Igor Vaynberg <ig...@gmail.com>.
so write the models against 2.0. they will be exactly the same in
1.4branch. code examples i guess you can leave for later?
-igor
On 3/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> A very big problem for Martijn and me is actually that we can't go on
> with writing until 1.4 is created. Models are everywhere in the book,
> including a separate chapter, and they are based on the 2.0 models
> currently. Martijn and me would have to decide on whether to target
> 1.4 or 1.5 but it would be either of them. Freezing the writing for a
> few weeks is really unacceptable for us. I understand your problems of
> accepting the model change for 1.3, but if it doesn't get in there -
> which is fine - Martijn and me need that 1.4 branch fast.
>
> Eelco
>
>
> On 3/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > This sounds good to me. The main point of critique I can think of is
> > that so far we haven't be able to do releases very fast. So in that
> > sense, the time schedule is probably very unrealistic. However, there
> > is nothing I would like more then us to be able to actually *do*
> > releases fast, so if this is another carrot on a stick to make *that*
> > happen, I'm all for it.
> >
> > Eelco
> >
> >
> > On 3/7/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > pasted from almaw's email on @user
> > >
> > > -igor
> > >
> > > -------------------------- 8><
> --------------------------------------------
> > >
> > > In my opinion we could, within the next:
> > > -----------------------------------------
> > > 1 week - Push 1.3-betas as-is.
> > > 2/3 weeks - Bug fix as people test it and push out rc's when
> > > we feel it's solid and stable.
> > > 4 weeks - Rename 1.x branch to 1.3.x.
> > > - Release 1.3.0 final and put 1.3.x immediately into
> > > maintenance mode.
> > > - Create 1.4.x branch from 1.3.0 tag.
> > > - Merge the model changes from trunk to 1.4.x.
> > > - Backport anything else from trunk to 1.4.x that's
> > > not JDK5-specific.
> > > 6 weeks - Push out 1.4-betas
> > > 7/8 weeks - Push out 1.4-rc's
> > > 9 weeks - Push out 1.4.0 final
> > > - Create 1.5.x branch from 1.4.0 tag.
> > > - Backport/add generics, covariance and other JDK 5 trunk
> > > features to the 1.5.x branch.
> > > - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> > > 14+ weeks - Release 1.5.0
> > >
> > > Suggestions to make this work:
> > > ------------------------------
> > > We won't backport from 1.4.x -> 1.3.x.
> > > We won't actively develop trunk.
> > > We will push 1.4 out very soon after 1.3, and encourage migration.
> > > We will have this in a public roadmap so people can see it coming.
> > >
> > > Notes on what you think is insanity, but actually isn't:
> > > --------------------------------------------------------
> > > We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
> > > 1.5.x and what's currently trunk). This may seem like madness to you,
> > > but I reckon it isn't:
> > >
> > > During 1.3 development, 2.x is low activity, 1.2.x negligible.
> > > During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> > > During 1.5 development, only 1.4.x will also be quite active.
> > >
> > > Once 1.5.0 is out, we can properly deprecate 2.0. People currently
> using
> > > it may not like being told to migrate to 1.5.x, but that shouldn't be
> > > too hard (much less hard than going from 1.3->2.0) and there shouldn't
> > > be too many of them. I guess that's the price you sometimes pay for
> > > using unreleased software. :-/
> > >
> > > I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> > > obviously encourage core developers and patchers to upgrade their
> sites
> > > to use 1.5.x, do active development on that, and therefore try to only
> > > ever backport from 1.5.x to 1.4.x, not forward-port the other way
> around.
> > >
> > > If you think I'm smoking crack, the above is utterly unreasonable, you
> > > want to kick me out of the gang, or you have any better ideas or
> > > suggestions as to how to keep everyone happy, please shout now. :-)
> > >
> > > Best regards,
> > >
> > > Alastair
> > >
> >
>
Re: roadmap
Posted by Eelco Hillenius <ee...@gmail.com>.
Up to now we didn't release a thing from 1.3 nor 2.0. I'm totally for
releasing something 1.3-ish this weekend, if only for the selfish
reason that I want to stabilize on a release for one of the branches
of the system I'm working on. So I would like - and I'm sure others as
well - to have *some* official version, whatever the version name.
Now, personally, I'm in favor of doing anything in 1.3, but I can see
Al's point and if he feels that strongly about it, I'm flexible (even
though it gives Martijn and me more pain in the writing). The big
thing that I'm afraid of, just looking at how we have functioned as a
project so far, is that these couple of weeks are going to be a couple
of months.
Eelco
On 3/7/07, Johan Compagner <jc...@gmail.com> wrote:
> thats another good reason to combine the 1.3 and 1.4
> I still don't get it why release that fast and why let people completely
> walk over there
> code twice. If i as a user i am horrified. Do it once and be over with it.
>
>
> johan
>
>
> On 3/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > A very big problem for Martijn and me is actually that we can't go on
> > with writing until 1.4 is created. Models are everywhere in the book,
> > including a separate chapter, and they are based on the 2.0 models
> > currently. Martijn and me would have to decide on whether to target
> > 1.4 or 1.5 but it would be either of them. Freezing the writing for a
> > few weeks is really unacceptable for us. I understand your problems of
> > accepting the model change for 1.3, but if it doesn't get in there -
> > which is fine - Martijn and me need that 1.4 branch fast.
> >
> > Eelco
> >
> >
> > On 3/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > This sounds good to me. The main point of critique I can think of is
> > > that so far we haven't be able to do releases very fast. So in that
> > > sense, the time schedule is probably very unrealistic. However, there
> > > is nothing I would like more then us to be able to actually *do*
> > > releases fast, so if this is another carrot on a stick to make *that*
> > > happen, I'm all for it.
> > >
> > > Eelco
> > >
> > >
> > > On 3/7/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > > pasted from almaw's email on @user
> > > >
> > > > -igor
> > > >
> > > > -------------------------- 8><
> > --------------------------------------------
> > > >
> > > > In my opinion we could, within the next:
> > > > -----------------------------------------
> > > > 1 week - Push 1.3-betas as-is.
> > > > 2/3 weeks - Bug fix as people test it and push out rc's when
> > > > we feel it's solid and stable.
> > > > 4 weeks - Rename 1.x branch to 1.3.x.
> > > > - Release 1.3.0 final and put 1.3.x immediately into
> > > > maintenance mode.
> > > > - Create 1.4.x branch from 1.3.0 tag.
> > > > - Merge the model changes from trunk to 1.4.x.
> > > > - Backport anything else from trunk to 1.4.x that's
> > > > not JDK5-specific.
> > > > 6 weeks - Push out 1.4-betas
> > > > 7/8 weeks - Push out 1.4-rc's
> > > > 9 weeks - Push out 1.4.0 final
> > > > - Create 1.5.x branch from 1.4.0 tag.
> > > > - Backport/add generics, covariance and other JDK 5 trunk
> > > > features to the 1.5.x branch.
> > > > - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> > > > 14+ weeks - Release 1.5.0
> > > >
> > > > Suggestions to make this work:
> > > > ------------------------------
> > > > We won't backport from 1.4.x -> 1.3.x.
> > > > We won't actively develop trunk.
> > > > We will push 1.4 out very soon after 1.3, and encourage migration.
> > > > We will have this in a public roadmap so people can see it coming.
> > > >
> > > > Notes on what you think is insanity, but actually isn't:
> > > > --------------------------------------------------------
> > > > We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
> > > > 1.5.x and what's currently trunk). This may seem like madness to you,
> > > > but I reckon it isn't:
> > > >
> > > > During 1.3 development, 2.x is low activity, 1.2.x negligible.
> > > > During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> > > > During 1.5 development, only 1.4.x will also be quite active.
> > > >
> > > > Once 1.5.0 is out, we can properly deprecate 2.0. People currently
> > using
> > > > it may not like being told to migrate to 1.5.x, but that shouldn't be
> > > > too hard (much less hard than going from 1.3->2.0) and there shouldn't
> > > > be too many of them. I guess that's the price you sometimes pay for
> > > > using unreleased software. :-/
> > > >
> > > > I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> > > > obviously encourage core developers and patchers to upgrade their
> > sites
> > > > to use 1.5.x, do active development on that, and therefore try to only
> > > > ever backport from 1.5.x to 1.4.x, not forward-port the other way
> > around.
> > > >
> > > > If you think I'm smoking crack, the above is utterly unreasonable, you
> > > > want to kick me out of the gang, or you have any better ideas or
> > > > suggestions as to how to keep everyone happy, please shout now. :-)
> > > >
> > > > Best regards,
> > > >
> > > > Alastair
> > > >
> > >
> >
>
Re: roadmap
Posted by Johan Compagner <jc...@gmail.com>.
thats another good reason to combine the 1.3 and 1.4
I still don't get it why release that fast and why let people completely
walk over there
code twice. If i as a user i am horrified. Do it once and be over with it.
johan
On 3/8/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> A very big problem for Martijn and me is actually that we can't go on
> with writing until 1.4 is created. Models are everywhere in the book,
> including a separate chapter, and they are based on the 2.0 models
> currently. Martijn and me would have to decide on whether to target
> 1.4 or 1.5 but it would be either of them. Freezing the writing for a
> few weeks is really unacceptable for us. I understand your problems of
> accepting the model change for 1.3, but if it doesn't get in there -
> which is fine - Martijn and me need that 1.4 branch fast.
>
> Eelco
>
>
> On 3/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > This sounds good to me. The main point of critique I can think of is
> > that so far we haven't be able to do releases very fast. So in that
> > sense, the time schedule is probably very unrealistic. However, there
> > is nothing I would like more then us to be able to actually *do*
> > releases fast, so if this is another carrot on a stick to make *that*
> > happen, I'm all for it.
> >
> > Eelco
> >
> >
> > On 3/7/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > > pasted from almaw's email on @user
> > >
> > > -igor
> > >
> > > -------------------------- 8><
> --------------------------------------------
> > >
> > > In my opinion we could, within the next:
> > > -----------------------------------------
> > > 1 week - Push 1.3-betas as-is.
> > > 2/3 weeks - Bug fix as people test it and push out rc's when
> > > we feel it's solid and stable.
> > > 4 weeks - Rename 1.x branch to 1.3.x.
> > > - Release 1.3.0 final and put 1.3.x immediately into
> > > maintenance mode.
> > > - Create 1.4.x branch from 1.3.0 tag.
> > > - Merge the model changes from trunk to 1.4.x.
> > > - Backport anything else from trunk to 1.4.x that's
> > > not JDK5-specific.
> > > 6 weeks - Push out 1.4-betas
> > > 7/8 weeks - Push out 1.4-rc's
> > > 9 weeks - Push out 1.4.0 final
> > > - Create 1.5.x branch from 1.4.0 tag.
> > > - Backport/add generics, covariance and other JDK 5 trunk
> > > features to the 1.5.x branch.
> > > - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> > > 14+ weeks - Release 1.5.0
> > >
> > > Suggestions to make this work:
> > > ------------------------------
> > > We won't backport from 1.4.x -> 1.3.x.
> > > We won't actively develop trunk.
> > > We will push 1.4 out very soon after 1.3, and encourage migration.
> > > We will have this in a public roadmap so people can see it coming.
> > >
> > > Notes on what you think is insanity, but actually isn't:
> > > --------------------------------------------------------
> > > We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
> > > 1.5.x and what's currently trunk). This may seem like madness to you,
> > > but I reckon it isn't:
> > >
> > > During 1.3 development, 2.x is low activity, 1.2.x negligible.
> > > During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> > > During 1.5 development, only 1.4.x will also be quite active.
> > >
> > > Once 1.5.0 is out, we can properly deprecate 2.0. People currently
> using
> > > it may not like being told to migrate to 1.5.x, but that shouldn't be
> > > too hard (much less hard than going from 1.3->2.0) and there shouldn't
> > > be too many of them. I guess that's the price you sometimes pay for
> > > using unreleased software. :-/
> > >
> > > I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> > > obviously encourage core developers and patchers to upgrade their
> sites
> > > to use 1.5.x, do active development on that, and therefore try to only
> > > ever backport from 1.5.x to 1.4.x, not forward-port the other way
> around.
> > >
> > > If you think I'm smoking crack, the above is utterly unreasonable, you
> > > want to kick me out of the gang, or you have any better ideas or
> > > suggestions as to how to keep everyone happy, please shout now. :-)
> > >
> > > Best regards,
> > >
> > > Alastair
> > >
> >
>
Re: roadmap
Posted by Eelco Hillenius <ee...@gmail.com>.
A very big problem for Martijn and me is actually that we can't go on
with writing until 1.4 is created. Models are everywhere in the book,
including a separate chapter, and they are based on the 2.0 models
currently. Martijn and me would have to decide on whether to target
1.4 or 1.5 but it would be either of them. Freezing the writing for a
few weeks is really unacceptable for us. I understand your problems of
accepting the model change for 1.3, but if it doesn't get in there -
which is fine - Martijn and me need that 1.4 branch fast.
Eelco
On 3/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
> This sounds good to me. The main point of critique I can think of is
> that so far we haven't be able to do releases very fast. So in that
> sense, the time schedule is probably very unrealistic. However, there
> is nothing I would like more then us to be able to actually *do*
> releases fast, so if this is another carrot on a stick to make *that*
> happen, I'm all for it.
>
> Eelco
>
>
> On 3/7/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > pasted from almaw's email on @user
> >
> > -igor
> >
> > -------------------------- 8>< --------------------------------------------
> >
> > In my opinion we could, within the next:
> > -----------------------------------------
> > 1 week - Push 1.3-betas as-is.
> > 2/3 weeks - Bug fix as people test it and push out rc's when
> > we feel it's solid and stable.
> > 4 weeks - Rename 1.x branch to 1.3.x.
> > - Release 1.3.0 final and put 1.3.x immediately into
> > maintenance mode.
> > - Create 1.4.x branch from 1.3.0 tag.
> > - Merge the model changes from trunk to 1.4.x.
> > - Backport anything else from trunk to 1.4.x that's
> > not JDK5-specific.
> > 6 weeks - Push out 1.4-betas
> > 7/8 weeks - Push out 1.4-rc's
> > 9 weeks - Push out 1.4.0 final
> > - Create 1.5.x branch from 1.4.0 tag.
> > - Backport/add generics, covariance and other JDK 5 trunk
> > features to the 1.5.x branch.
> > - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> > 14+ weeks - Release 1.5.0
> >
> > Suggestions to make this work:
> > ------------------------------
> > We won't backport from 1.4.x -> 1.3.x.
> > We won't actively develop trunk.
> > We will push 1.4 out very soon after 1.3, and encourage migration.
> > We will have this in a public roadmap so people can see it coming.
> >
> > Notes on what you think is insanity, but actually isn't:
> > --------------------------------------------------------
> > We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
> > 1.5.x and what's currently trunk). This may seem like madness to you,
> > but I reckon it isn't:
> >
> > During 1.3 development, 2.x is low activity, 1.2.x negligible.
> > During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> > During 1.5 development, only 1.4.x will also be quite active.
> >
> > Once 1.5.0 is out, we can properly deprecate 2.0. People currently using
> > it may not like being told to migrate to 1.5.x, but that shouldn't be
> > too hard (much less hard than going from 1.3->2.0) and there shouldn't
> > be too many of them. I guess that's the price you sometimes pay for
> > using unreleased software. :-/
> >
> > I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> > obviously encourage core developers and patchers to upgrade their sites
> > to use 1.5.x, do active development on that, and therefore try to only
> > ever backport from 1.5.x to 1.4.x, not forward-port the other way around.
> >
> > If you think I'm smoking crack, the above is utterly unreasonable, you
> > want to kick me out of the gang, or you have any better ideas or
> > suggestions as to how to keep everyone happy, please shout now. :-)
> >
> > Best regards,
> >
> > Alastair
> >
>
Re: roadmap
Posted by Eelco Hillenius <ee...@gmail.com>.
This sounds good to me. The main point of critique I can think of is
that so far we haven't be able to do releases very fast. So in that
sense, the time schedule is probably very unrealistic. However, there
is nothing I would like more then us to be able to actually *do*
releases fast, so if this is another carrot on a stick to make *that*
happen, I'm all for it.
Eelco
On 3/7/07, Igor Vaynberg <ig...@gmail.com> wrote:
> pasted from almaw's email on @user
>
> -igor
>
> -------------------------- 8>< --------------------------------------------
>
> In my opinion we could, within the next:
> -----------------------------------------
> 1 week - Push 1.3-betas as-is.
> 2/3 weeks - Bug fix as people test it and push out rc's when
> we feel it's solid and stable.
> 4 weeks - Rename 1.x branch to 1.3.x.
> - Release 1.3.0 final and put 1.3.x immediately into
> maintenance mode.
> - Create 1.4.x branch from 1.3.0 tag.
> - Merge the model changes from trunk to 1.4.x.
> - Backport anything else from trunk to 1.4.x that's
> not JDK5-specific.
> 6 weeks - Push out 1.4-betas
> 7/8 weeks - Push out 1.4-rc's
> 9 weeks - Push out 1.4.0 final
> - Create 1.5.x branch from 1.4.0 tag.
> - Backport/add generics, covariance and other JDK 5 trunk
> features to the 1.5.x branch.
> - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> 14+ weeks - Release 1.5.0
>
> Suggestions to make this work:
> ------------------------------
> We won't backport from 1.4.x -> 1.3.x.
> We won't actively develop trunk.
> We will push 1.4 out very soon after 1.3, and encourage migration.
> We will have this in a public roadmap so people can see it coming.
>
> Notes on what you think is insanity, but actually isn't:
> --------------------------------------------------------
> We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
> 1.5.x and what's currently trunk). This may seem like madness to you,
> but I reckon it isn't:
>
> During 1.3 development, 2.x is low activity, 1.2.x negligible.
> During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> During 1.5 development, only 1.4.x will also be quite active.
>
> Once 1.5.0 is out, we can properly deprecate 2.0. People currently using
> it may not like being told to migrate to 1.5.x, but that shouldn't be
> too hard (much less hard than going from 1.3->2.0) and there shouldn't
> be too many of them. I guess that's the price you sometimes pay for
> using unreleased software. :-/
>
> I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> obviously encourage core developers and patchers to upgrade their sites
> to use 1.5.x, do active development on that, and therefore try to only
> ever backport from 1.5.x to 1.4.x, not forward-port the other way around.
>
> If you think I'm smoking crack, the above is utterly unreasonable, you
> want to kick me out of the gang, or you have any better ideas or
> suggestions as to how to keep everyone happy, please shout now. :-)
>
> Best regards,
>
> Alastair
>
Re: [Vote] roadmap
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Steven Zou:
> Why not go to 2.0 with all strength directly? and make
> 1.2.x only bugfix. I think that the frequent release
> plan(1.3,1.4,1.5...) is one bad idea.these will confuse many
> users...
Uh? Every piece of software I know releases often, and avoids
API breaks. I don't understand your point. Currently we
have a frozen 1.2.x branch, a late-to-be-released 1.3, and a
soon-to-be-dead and API-incompatible 2.0. The roadmap reflects
the feeling that we need to focus on 1.x, avoid big API breaks,
and release often. That's what the users want I think.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: [Vote] roadmap
Posted by Steven Zou <jg...@gmail.com>.
Why not go to 2.0 with all strength directly? and make 1.2.x only bugfix.
I think that the frequent release plan(1.3,1.4,1.5...) is one bad idea.these
will confuse many users...
igor.vaynberg wrote:
>
> pasted from almaw's email on @user
>
> -igor
>
> -------------------------- 8><
> --------------------------------------------
>
> In my opinion we could, within the next:
> -----------------------------------------
> 1 week - Push 1.3-betas as-is.
> 2/3 weeks - Bug fix as people test it and push out rc's when
> we feel it's solid and stable.
> 4 weeks - Rename 1.x branch to 1.3.x.
> - Release 1.3.0 final and put 1.3.x immediately into
> maintenance mode.
> - Create 1.4.x branch from 1.3.0 tag.
> - Merge the model changes from trunk to 1.4.x.
> - Backport anything else from trunk to 1.4.x that's
> not JDK5-specific.
> 6 weeks - Push out 1.4-betas
> 7/8 weeks - Push out 1.4-rc's
> 9 weeks - Push out 1.4.0 final
> - Create 1.5.x branch from 1.4.0 tag.
> - Backport/add generics, covariance and other JDK 5 trunk
> features to the 1.5.x branch.
> - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> 14+ weeks - Release 1.5.0
>
> Suggestions to make this work:
> ------------------------------
> We won't backport from 1.4.x -> 1.3.x.
> We won't actively develop trunk.
> We will push 1.4 out very soon after 1.3, and encourage migration.
> We will have this in a public roadmap so people can see it coming.
>
> Notes on what you think is insanity, but actually isn't:
> --------------------------------------------------------
> We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
> 1.5.x and what's currently trunk). This may seem like madness to you,
> but I reckon it isn't:
>
> During 1.3 development, 2.x is low activity, 1.2.x negligible.
> During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> During 1.5 development, only 1.4.x will also be quite active.
>
> Once 1.5.0 is out, we can properly deprecate 2.0. People currently using
> it may not like being told to migrate to 1.5.x, but that shouldn't be
> too hard (much less hard than going from 1.3->2.0) and there shouldn't
> be too many of them. I guess that's the price you sometimes pay for
> using unreleased software. :-/
>
> I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> obviously encourage core developers and patchers to upgrade their sites
> to use 1.5.x, do active development on that, and therefore try to only
> ever backport from 1.5.x to 1.4.x, not forward-port the other way around.
>
> If you think I'm smoking crack, the above is utterly unreasonable, you
> want to kick me out of the gang, or you have any better ideas or
> suggestions as to how to keep everyone happy, please shout now. :-)
>
> Best regards,
>
> Alastair
>
>
--
View this message in context: http://www.nabble.com/roadmap-tf3366743.html#a9371386
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: roadmap
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Johan Compagner:
> What should by the way all the users of 2.0 now do? They
> shouldn't backport to 1.3 that would be completely stupid so the
> have to keep using 2.0 until we make 1.4 available? Because if
> they do backport first to 1.3 to at least be on a stable branch
> or active develop branch then we screw them twice. first
> backport from 2.0 to 1.3 then they have to use the old model
> style then 1.4 comes along and they have to redo there model 2.0
> style.
People using 2.0 will switch to the 1.x branch when the Model
refactor is done. You're discussing names and version numbers,
but the real issue is about what features go in what version. You
say don't go too quickly, but this is the goal of the roadmap: to
plan when the features are backported to avoid being too chaotic.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: roadmap
Posted by Johan Compagner <jc...@gmail.com>.
What should by the way all the users of 2.0 now do?
They shouldn't backport to 1.3 that would be completely stupid
so the have to keep using 2.0 until we make 1.4 available?
Because if they do backport first to 1.3 to at least be on a stable branch
or active develop branch
then we screw them twice. first backport from 2.0 to 1.3 then they have to
use the old model style
then 1.4 comes along and they have to redo there model 2.0 style.
johan
On 3/8/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> pasted from almaw's email on @user
>
> -igor
>
> -------------------------- 8><
> --------------------------------------------
>
> In my opinion we could, within the next:
> -----------------------------------------
> 1 week - Push 1.3-betas as-is.
> 2/3 weeks - Bug fix as people test it and push out rc's when
> we feel it's solid and stable.
> 4 weeks - Rename 1.x branch to 1.3.x.
> - Release 1.3.0 final and put 1.3.x immediately into
> maintenance mode.
> - Create 1.4.x branch from 1.3.0 tag.
> - Merge the model changes from trunk to 1.4.x.
> - Backport anything else from trunk to 1.4.x that's
> not JDK5-specific.
> 6 weeks - Push out 1.4-betas
> 7/8 weeks - Push out 1.4-rc's
> 9 weeks - Push out 1.4.0 final
> - Create 1.5.x branch from 1.4.0 tag.
> - Backport/add generics, covariance and other JDK 5 trunk
> features to the 1.5.x branch.
> - Move trunk to "2.0_deprecated_-_use_1.5.x_instead"
> 14+ weeks - Release 1.5.0
>
> Suggestions to make this work:
> ------------------------------
> We won't backport from 1.4.x -> 1.3.x.
> We won't actively develop trunk.
> We will push 1.4 out very soon after 1.3, and encourage migration.
> We will have this in a public roadmap so people can see it coming.
>
> Notes on what you think is insanity, but actually isn't:
> --------------------------------------------------------
> We will of course end up with five(!) branches (1.2.x, 1.3.x, 1.4.x,
> 1.5.x and what's currently trunk). This may seem like madness to you,
> but I reckon it isn't:
>
> During 1.3 development, 2.x is low activity, 1.2.x negligible.
> During 1.4 development, 1.3.x and 2.x are low, 1.2.x negligible.
> During 1.5 development, only 1.4.x will also be quite active.
>
> Once 1.5.0 is out, we can properly deprecate 2.0. People currently using
> it may not like being told to migrate to 1.5.x, but that shouldn't be
> too hard (much less hard than going from 1.3->2.0) and there shouldn't
> be too many of them. I guess that's the price you sometimes pay for
> using unreleased software. :-/
>
> I'd envisage 1.4.x will require some backports from 1.5.x. We'd
> obviously encourage core developers and patchers to upgrade their sites
> to use 1.5.x, do active development on that, and therefore try to only
> ever backport from 1.5.x to 1.4.x, not forward-port the other way around.
>
> If you think I'm smoking crack, the above is utterly unreasonable, you
> want to kick me out of the gang, or you have any better ideas or
> suggestions as to how to keep everyone happy, please shout now. :-)
>
> Best regards,
>
> Alastair
>