You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2005/09/01 10:06:48 UTC
Releasing 2.1.8, when?
My original idea was to release 2.1.8 after the GT, so announcing the
code freeze the week after the GT and releasing one week later. In the
last years, we had the famous bug hunt at the GT and fixed/improved
several things. This year we have two days for the hackathon so we
should be able to do even more.
But we can release sooner if required; I think the current state is very
stable.
I think from 2.1.8 we should simply release every two months. So
everyone (developers and users) have a fixed date. So this is a little
bit more of agile development as we are using fixed sprints :)
Of course if there are showstoppers we will make an exception.
WDYT?
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.1.8, when?
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Sep 1, 2005, at 1:06 AM, Carsten Ziegeler wrote:
> I think from 2.1.8 we should simply release every two months. So
> everyone (developers and users) have a fixed date.
+1
Re: Releasing 2.1.8, when?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 1 Sep 2005, at 09:06, Carsten Ziegeler wrote:
> But we can release sooner if required; I think the current state is
> very
> stable.
>
> I think from 2.1.8 we should simply release every two months. So
> everyone (developers and users) have a fixed date. So this is a little
> bit more of agile development as we are using fixed sprints :)
> Of course if there are showstoppers we will make an exception.
>
> WDYT?
Love it! :-D +1
Pier
Re: Releasing 2.1.8, when?
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
> Ralph Goers wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Right, but making it "internal" is stronger as it means "don't use
>>> it", as internals can change also without notice.
>>>
>> That is fine if it accomplishes what you want it to. I got the
>> impression that your position with the location stuff was more of a
>> "use at your own risk as this isn't fully completed - but I would
>> like your feedback".
>
> Ah yes. Oh damn, how difficult it is to ask people to test new
> features while still warning them that they should nor rely on it!!!
I don't know. I think the community did a pretty good job of that with
Woody. It was quite clear that it was experimental yet folks tried it
and I don't recall anybody complaining when it was all renamed to become
the forms block. Maybe because Woody is still around.
I suppose one way would be to initially name stuff as
o.a.c.whatever.experimental.ClassName. Then when you have it working
create a clone at o.a.c.whatever.ClassName and deprecate the
experimental stuff. An even better name would be
o.a.c.whatever.testme.ClassName ;-)
>
>
Re: Releasing 2.1.8, when?
Posted by Sylvain Wallez <sy...@apache.org>.
Ralph Goers wrote:
> Sylvain Wallez wrote:
>
>> Ralph Goers wrote:
>>
>>> "Internal" to me means that no application should ever use it and
>>> that it might be removed at a future time. What you have described
>>> is more along the lines of "under development" or "in testing".
>>> i.e. use at your own risk.
>>
>>
>>
>> Right, but making it "internal" is stronger as it means "don't use
>> it", as internals can change also without notice.
>>
> That is fine if it accomplishes what you want it to. I got the
> impression that your position with the location stuff was more of a
> "use at your own risk as this isn't fully completed - but I would like
> your feedback".
Ah yes. Oh damn, how difficult it is to ask people to test new features
while still warning them that they should nor rely on it!!!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Releasing 2.1.8, when?
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
> Ralph Goers wrote:
>
>> "Internal" to me means that no application should ever use it and
>> that it might be removed at a future time. What you have described
>> is more along the lines of "under development" or "in testing". i.e.
>> use at your own risk.
>
>
> Right, but making it "internal" is stronger as it means "don't use
> it", as internals can change also without notice.
>
That is fine if it accomplishes what you want it to. I got the
impression that your position with the location stuff was more of a "use
at your own risk as this isn't fully completed - but I would like your
feedback".
Ralph
Re: Releasing 2.1.8, when?
Posted by Sylvain Wallez <sy...@apache.org>.
Ralph Goers wrote:
> Sylvain Wallez wrote:
>
>> Although I agree with the general principle of shorter release
>> cycles, we have to define a policy regarding new features introduced
>> in these frequent releases and the associated contracts. Again,
>> stable / unstable state, but at a finer intra-block level.
>>
>> Let's take an example with the new Location stuff. It's very cool and
>> a lot of people will want to use it. However, we may not consider the
>> API totally finished (there are still a few minor changes I'd like to
>> do for it to be cleaner and more straightforward). What if we make a
>> release now? The contracts will have changed a bit in the next release!
>
>
> Just update the Javadoc to say what you want to say. If it isn't
> completely stable yet just try to make sure it doesn't stay that way
> for too long.
That's the point: periodic releases may clash with ongoing development,
meaning an interim state for one release. Now as Daniel rightly pointed
out, having fixed dates will likely change our developer habits.
>> So this leads back to a discussion we already had: marking some APIs
>> as internal, so that people are warned that they should not base
>> their code on it. The internal status can be used for things that are
>> really internal (like all the environment handling stuff) and things
>> that are fully functionnal (i.e. "stable" from a bug point of view)
>> but on which we still reserve the right to do some modifications.
>
>
> "Internal" to me means that no application should ever use it and that
> it might be removed at a future time. What you have described is more
> along the lines of "under development" or "in testing". i.e. use at
> your own risk.
Right, but making it "internal" is stronger as it means "don't use it",
as internals can change also without notice.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Releasing 2.1.8, when?
Posted by Ralph Goers <Ra...@dslextreme.com>.
Sylvain Wallez wrote:
>
> Although I agree with the general principle of shorter release cycles,
> we have to define a policy regarding new features introduced in these
> frequent releases and the associated contracts. Again, stable /
> unstable state, but at a finer intra-block level.
>
> Let's take an example with the new Location stuff. It's very cool and
> a lot of people will want to use it. However, we may not consider the
> API totally finished (there are still a few minor changes I'd like to
> do for it to be cleaner and more straightforward). What if we make a
> release now? The contracts will have changed a bit in the next release!
Just update the Javadoc to say what you want to say. If it isn't
completely stable yet just try to make sure it doesn't stay that way for
too long.
>
> So this leads back to a discussion we already had: marking some APIs
> as internal, so that people are warned that they should not base their
> code on it. The internal status can be used for things that are really
> internal (like all the environment handling stuff) and things that are
> fully functionnal (i.e. "stable" from a bug point of view) but on
> which we still reserve the right to do some modifications.
"Internal" to me means that no application should ever use it and that
it might be removed at a future time. What you have described is more
along the lines of "under development" or "in testing". i.e. use at
your own risk.
>
> Another solution of course would be to use branches, but this isn't
> very practical for fine-grained things like outlined above.
>
> Just some thoughts...
>
> Sylvain
>
Ralph
Re: Releasing 2.1.8, when?
Posted by Jean-Baptiste Quenot <jb...@anyware-tech.com>.
* Sylvain Wallez:
> > Carsten Ziegeler wrote:
> >
> > > But we can release sooner if required; I think the current
> > > state is very stable.
>
> Although I agree with the general principle of shorter release
> cycles, we have to define a policy regarding new features
> introduced in these frequent releases and the associated
> contracts.
It would be great also to have a policy concerning bugs. Please
find below a list of critical bugs I submitted, all of them are
showstoppers:
[PATCH] forms-field-styling.xsl validation-message with apostrophes
http://issues.apache.org/bugzilla/show_bug.cgi?id=35574
[PATCH] XMLDBSource cannot find SerializerSelector
http://issues.apache.org/bugzilla/show_bug.cgi?id=35575
JXPath expressions within JX-CForms template
http://issues.apache.org/bugzilla/show_bug.cgi?id=36462
Thanks in advance,
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/
Re: Releasing 2.1.8, when?
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> "editions"? Do you mean the new features? Yes, that's the idea: put on
> them a special flag so that people know that these are used internally
> but that they should not have their code depend on them.
>
Gosh, someday I really have to read what I'm typing - this happens when
you are used to type in java editors or word that do auto-completion and
corrections for you...sorry, I meant "additions" which are of course the
new features.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.1.8, when?
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>Although I agree with the general principle of shorter release cycles,
>>we have to define a policy regarding new features introduced in these
>>frequent releases and the associated contracts. Again, stable / unstable
>>state, but at a finer intra-block level.
>>
>>Let's take an example with the new Location stuff. It's very cool and a
>>lot of people will want to use it. However, we may not consider the API
>>totally finished (there are still a few minor changes I'd like to do for
>>it to be cleaner and more straightforward). What if we make a release
>>now? The contracts will have changed a bit in the next release!
>>
>>So this leads back to a discussion we already had: marking some APIs as
>>internal, so that people are warned that they should not base their code
>>on it. The internal status can be used for things that are really
>>internal (like all the environment handling stuff) and things that are
>>fully functionnal (i.e. "stable" from a bug point of view) but on which
>>we still reserve the right to do some modifications.
>>
>>Another solution of course would be to use branches, but this isn't very
>>practical for fine-grained things like outlined above.
>>
>>
>>
>Yepp, that's all true and we agreed several times to mark the api, but
>unfortunately it never happened :(
>With your location stuff, I think the api changes effect only java
>developers, so I think we can even release the current state and change
>things there later on.
>
>
Hmm... Java APIs are our contracts also...
>Now, if we have a fixed schedule (every two months), people know that
>they have to "finish" new work before the next release and they know
>when this release will be. This does not solve the problem you describe,
>but it might lessen it a little bit.
>
>
That's right. And at the very end, some unfinished features (API-wise)
can be temporarily removed to make the release and re-added afterwards.
>Ok, so, what about just marking those new editions with TODO or NOT
>FINISHED or whatever?
>
>
"editions"? Do you mean the new features? Yes, that's the idea: put on
them a special flag so that people know that these are used internally
but that they should not have their code depend on them.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Releasing 2.1.8, when?
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Although I agree with the general principle of shorter release cycles,
> we have to define a policy regarding new features introduced in these
> frequent releases and the associated contracts. Again, stable / unstable
> state, but at a finer intra-block level.
>
> Let's take an example with the new Location stuff. It's very cool and a
> lot of people will want to use it. However, we may not consider the API
> totally finished (there are still a few minor changes I'd like to do for
> it to be cleaner and more straightforward). What if we make a release
> now? The contracts will have changed a bit in the next release!
>
> So this leads back to a discussion we already had: marking some APIs as
> internal, so that people are warned that they should not base their code
> on it. The internal status can be used for things that are really
> internal (like all the environment handling stuff) and things that are
> fully functionnal (i.e. "stable" from a bug point of view) but on which
> we still reserve the right to do some modifications.
>
> Another solution of course would be to use branches, but this isn't very
> practical for fine-grained things like outlined above.
>
Yepp, that's all true and we agreed several times to mark the api, but
unfortunately it never happened :(
With your location stuff, I think the api changes effect only java
developers, so I think we can even release the current state and change
things there later on.
Now, if we have a fixed schedule (every two months), people know that
they have to "finish" new work before the next release and they know
when this release will be. This does not solve the problem you describe,
but it might lessen it a little bit.
Ok, so, what about just marking those new editions with TODO or NOT
FINISHED or whatever?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.1.8, when?
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Carsten Ziegeler wrote:
>
>> My original idea was to release 2.1.8 after the GT, so announcing the
>> code freeze the week after the GT and releasing one week later. In the
>> last years, we had the famous bug hunt at the GT and fixed/improved
>> several things. This year we have two days for the hackathon so we
>> should be able to do even more.
>>
>> But we can release sooner if required; I think the current state is very
>> stable.
>>
>> I think from 2.1.8 we should simply release every two months. So
>> everyone (developers and users) have a fixed date. So this is a little
>> bit more of agile development as we are using fixed sprints :)
>> Of course if there are showstoppers we will make an exception.
>
Although I agree with the general principle of shorter release cycles,
we have to define a policy regarding new features introduced in these
frequent releases and the associated contracts. Again, stable / unstable
state, but at a finer intra-block level.
Let's take an example with the new Location stuff. It's very cool and a
lot of people will want to use it. However, we may not consider the API
totally finished (there are still a few minor changes I'd like to do for
it to be cleaner and more straightforward). What if we make a release
now? The contracts will have changed a bit in the next release!
So this leads back to a discussion we already had: marking some APIs as
internal, so that people are warned that they should not base their code
on it. The internal status can be used for things that are really
internal (like all the environment handling stuff) and things that are
fully functionnal (i.e. "stable" from a bug point of view) but on which
we still reserve the right to do some modifications.
Another solution of course would be to use branches, but this isn't very
practical for fine-grained things like outlined above.
Just some thoughts...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Releasing 2.1.8, when?
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 1 sept. 05, à 10:14, Daniel Fagerstrom a écrit :
> Carsten Ziegeler wrote:
>> ...I think from 2.1.8 we should simply release every two months....
> Big +1
>
> Release 2.1.8 now (or soon), and then every 2nd month..
Same here, +1
-Bertrand
Re: Releasing 2.1.8, when?
Posted by Joerg Heinicke <jo...@gmx.de>.
On 01.09.2005 10:14, Daniel Fagerstrom wrote:
> Release 2.1.8 now (or soon), and then every 2nd month.
+1
Joerg
Re: Releasing 2.1.8, when?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
>My original idea was to release 2.1.8 after the GT, so announcing the
>code freeze the week after the GT and releasing one week later. In the
>last years, we had the famous bug hunt at the GT and fixed/improved
>several things. This year we have two days for the hackathon so we
>should be able to do even more.
>
>But we can release sooner if required; I think the current state is very
>stable.
>
>I think from 2.1.8 we should simply release every two months. So
>everyone (developers and users) have a fixed date. So this is a little
>bit more of agile development as we are using fixed sprints :)
>Of course if there are showstoppers we will make an exception.
>
>WDYT?
>
>
>
Big +1
Release 2.1.8 now (or soon), and then every 2nd month. Eclipse have a 6
week cycle, and some routine about how what kind of work that is done
during different phases:
http://www.artima.com/lejava/articles/eclipse_culture.html.
/Daniel
Re: Releasing 2.1.8, when?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
> My original idea was to release 2.1.8 after the GT, so announcing the
> code freeze the week after the GT and releasing one week later. In the
> last years, we had the famous bug hunt at the GT and fixed/improved
> several things. This year we have two days for the hackathon so we
> should be able to do even more.
>
> But we can release sooner if required; I think the current state is very
> stable.
+1
> I think from 2.1.8 we should simply release every two months. So
> everyone (developers and users) have a fixed date. So this is a little
> bit more of agile development as we are using fixed sprints :)
> Of course if there are showstoppers we will make an exception.
+1
Vadim
Re: Releasing 2.1.8, when?
Posted by Sylvain Wallez <sy...@apache.org>.
Daniel Fagerstrom wrote:
> Andrew Savory wrote:
>
>>
>> Sounds good ... the problem we have currently with "ship it when
>> it's ready" is we rarely agree on when it is ready ;-) The only
>> thing I'm wondering about is if every two months isn't a little fast
>> for the current rate of change in the 2.1* series?
>
>
> A main point about shipping every second month is that we create a
> habit to deliver regulary and in time and that we will improve our
> routines so that we make it easy to do the shipping and assesing the
> quality of the release. If not that much have happened since the last
> release, it will make it easier to ship the next one and it makes it
> less dramatic for the users to uppgrade.
>
> Currently when we ship rather selldom, people want to do a lot of last
> minute additions as they know that they have to wait half a year to
> make it part of a relase otherwise. These additions makes testing
> harder and makes the deadlines slip.
>
> Furthermore the only way to make features really stable is to release
> them and get "real" usage, user feedback, bug fixes and extensions on
> them.
These are really very good points.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Releasing 2.1.8, when?
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Andrew Savory wrote:
> Hi,
>
> On 1 Sep 2005, at 09:06, Carsten Ziegeler wrote:
>
>> But we can release sooner if required; I think the current state is
>> very
>> stable.
>
>
> Definitely +1 to release 2.1.8 ASAP.
>
>> I think from 2.1.8 we should simply release every two months. So
>> everyone (developers and users) have a fixed date. So this is a little
>> bit more of agile development as we are using fixed sprints :)
>> Of course if there are showstoppers we will make an exception.
>
>
> Sounds good ... the problem we have currently with "ship it when it's
> ready" is we rarely agree on when it is ready ;-) The only thing I'm
> wondering about is if every two months isn't a little fast for the
> current rate of change in the 2.1* series?
A main point about shipping every second month is that we create a habit
to deliver regulary and in time and that we will improve our routines so
that we make it easy to do the shipping and assesing the quality of the
release. If not that much have happened since the last release, it will
make it easier to ship the next one and it makes it less dramatic for
the users to uppgrade.
Currently when we ship rather selldom, people want to do a lot of last
minute additions as they know that they have to wait half a year to make
it part of a relase otherwise. These additions makes testing harder and
makes the deadlines slip.
Furthermore the only way to make features really stable is to release
them and get "real" usage, user feedback, bug fixes and extensions on them.
/Daniel
Re: Releasing 2.1.8, when?
Posted by Carsten Ziegeler <cz...@apache.org>.
Andrew Savory wrote:
>
> Sounds good ... the problem we have currently with "ship it when it's
> ready" is we rarely agree on when it is ready ;-) The only thing I'm
> wondering about is if every two months isn't a little fast for the
> current rate of change in the 2.1* series?
>
Yeah, might be - let's just start with two months and see if it works,
we can extend it to three months later on. But we shouldn't take a
longer period imho.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.1.8, when?
Posted by Andrew Savory <an...@luminas.co.uk>.
Hi,
On 1 Sep 2005, at 09:06, Carsten Ziegeler wrote:
> But we can release sooner if required; I think the current state is
> very
> stable.
Definitely +1 to release 2.1.8 ASAP.
> I think from 2.1.8 we should simply release every two months. So
> everyone (developers and users) have a fixed date. So this is a little
> bit more of agile development as we are using fixed sprints :)
> Of course if there are showstoppers we will make an exception.
Sounds good ... the problem we have currently with "ship it when it's
ready" is we rarely agree on when it is ready ;-) The only thing I'm
wondering about is if every two months isn't a little fast for the
current rate of change in the 2.1* series?
Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/