You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Joachim Dreimann <jo...@wandisco.com> on 2012/10/08 14:15:22 UTC
[Proposal] New release process
Hi everyone,
I'd like to propose a new release process for releases after 0.2 (once accepted).
Our current process (as I understand it):
- A milestone containing tickets we believe should be fixed for the release is created.
- Someone volunteers as release manager at an arbitrary point and packages up a release ready to be voted on.
- All uncompleted tickets in the milestone are moved to the next upcoming milestone.
In my opinion this is a messy process in which releases are unpredictable in scope and frequency.
Proposed new process:
1. Monthly release cycle with the packages ready to be voted on during the first full week of the month.
2. Milestones are for meaningful goals we're working towards. For example: Multi product, Responsive Layout, etc
3. Versions are set up reflecting the priority Milestones for the next release. When the release is being packaged up, all tickets fixed since the last release are assigned to the Version.
Obviously that would make the release frequency very predictable. I believe it also better reflects our actual working practice in the project better and make it easier for new contributors to pick up tickets. Meaningful Milestones allow us to track how we're progressing towards goals such as Multi Product or a Responsive Layout over several versions. Versions would clearly reflect what has been covered in each release, and bugs can be raised against them.
Longer term, with more contributors, we may get to a point where we're able to complete one or more whole milestones within each release cycle.
I'm sure we will come across situations where we need to make exceptions to this process, but please provide feedback on whether the plan itself is sound, not the possible exceptions.
Cheers,
Joe
Re: [Proposal] New release process
Posted by Greg Stein <gs...@gmail.com>.
My preference would be 2 to 4 :-)
In 2001, I was in a position to effectively dictate that speed for
Subversion. It was a huge win for the nascent community.
Cheers,
-g
On Oct 9, 2012 1:49 AM, "Peter Koželj" <pe...@digiverse.si> wrote:
> Actually I was not trying to propose Eclipse scheme for pre 1.0 releases.
> I think what we have right now is good enough until then.
>
> All we need is higher frequency, anything between 4 and 6 weeks sounds
> reasonable.
>
> Peter
>
> On Tue, Oct 9, 2012 at 9:21 AM, Greg Stein <gs...@gmail.com> wrote:
>
> > Too much process. Just make a release every N weeks. If something is
> done,
> > then it gets in. If not, then maybe it gets in the next release. Don't be
> > afraid to ship bugs because they will be fixed in two weeks in the next
> > release. This is not 1.0 -- there is no need to treat it with kid gloves.
> > Beat it up. If the release is total crap, then turn the crank and release
> > again a few days later.
> >
> > Don't get so hung up on what is in/out. Just make releases. Continually
> and
> > repeatably.
> >
> > The goal is activity, to build community.
> >
> > There should be (IMO) goals about features at this point in time.
> >
> > I disagree with the Eclipse numbering before 1.0. The project is not yet
> > managing feature releases. 0.2 then 0.3 ... Version numbers are cheap.
> Use
> > them.
> >
> > Cheers,
> > -g
> > On Oct 8, 2012 5:16 AM, "Joachim Dreimann" <
> joachim.dreimann@wandisco.com>
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I'd like to propose a new release process for releases after 0.2 (once
> > > accepted).
> > >
> > > Our current process (as I understand it):
> > > - A milestone containing tickets we believe should be fixed for the
> > > release is created.
> > > - Someone volunteers as release manager at an arbitrary point and
> > packages
> > > up a release ready to be voted on.
> > > - All uncompleted tickets in the milestone are moved to the next
> upcoming
> > > milestone.
> > >
> > > In my opinion this is a messy process in which releases are
> unpredictable
> > > in scope and frequency.
> > >
> > > Proposed new process:
> > > 1. Monthly release cycle with the packages ready to be voted on during
> > the
> > > first full week of the month.
> > > 2. Milestones are for meaningful goals we're working towards. For
> > example:
> > > Multi product, Responsive Layout, etc
> > > 3. Versions are set up reflecting the priority Milestones for the next
> > > release. When the release is being packaged up, all tickets fixed since
> > the
> > > last release are assigned to the Version.
> > >
> > > Obviously that would make the release frequency very predictable. I
> > > believe it also better reflects our actual working practice in the
> > project
> > > better and make it easier for new contributors to pick up tickets.
> > > Meaningful Milestones allow us to track how we're progressing towards
> > goals
> > > such as Multi Product or a Responsive Layout over several versions.
> > > Versions would clearly reflect what has been covered in each release,
> and
> > > bugs can be raised against them.
> > >
> > > Longer term, with more contributors, we may get to a point where we're
> > > able to complete one or more whole milestones within each release
> cycle.
> > >
> > > I'm sure we will come across situations where we need to make
> exceptions
> > > to this process, but please provide feedback on whether the plan itself
> > is
> > > sound, not the possible exceptions.
> > >
> > > Cheers,
> > > Joe
> >
>
Re: [Proposal] New release process
Posted by Peter Koželj <pe...@digiverse.si>.
Actually I was not trying to propose Eclipse scheme for pre 1.0 releases.
I think what we have right now is good enough until then.
All we need is higher frequency, anything between 4 and 6 weeks sounds
reasonable.
Peter
On Tue, Oct 9, 2012 at 9:21 AM, Greg Stein <gs...@gmail.com> wrote:
> Too much process. Just make a release every N weeks. If something is done,
> then it gets in. If not, then maybe it gets in the next release. Don't be
> afraid to ship bugs because they will be fixed in two weeks in the next
> release. This is not 1.0 -- there is no need to treat it with kid gloves.
> Beat it up. If the release is total crap, then turn the crank and release
> again a few days later.
>
> Don't get so hung up on what is in/out. Just make releases. Continually and
> repeatably.
>
> The goal is activity, to build community.
>
> There should be (IMO) goals about features at this point in time.
>
> I disagree with the Eclipse numbering before 1.0. The project is not yet
> managing feature releases. 0.2 then 0.3 ... Version numbers are cheap. Use
> them.
>
> Cheers,
> -g
> On Oct 8, 2012 5:16 AM, "Joachim Dreimann" <jo...@wandisco.com>
> wrote:
>
> > Hi everyone,
> >
> > I'd like to propose a new release process for releases after 0.2 (once
> > accepted).
> >
> > Our current process (as I understand it):
> > - A milestone containing tickets we believe should be fixed for the
> > release is created.
> > - Someone volunteers as release manager at an arbitrary point and
> packages
> > up a release ready to be voted on.
> > - All uncompleted tickets in the milestone are moved to the next upcoming
> > milestone.
> >
> > In my opinion this is a messy process in which releases are unpredictable
> > in scope and frequency.
> >
> > Proposed new process:
> > 1. Monthly release cycle with the packages ready to be voted on during
> the
> > first full week of the month.
> > 2. Milestones are for meaningful goals we're working towards. For
> example:
> > Multi product, Responsive Layout, etc
> > 3. Versions are set up reflecting the priority Milestones for the next
> > release. When the release is being packaged up, all tickets fixed since
> the
> > last release are assigned to the Version.
> >
> > Obviously that would make the release frequency very predictable. I
> > believe it also better reflects our actual working practice in the
> project
> > better and make it easier for new contributors to pick up tickets.
> > Meaningful Milestones allow us to track how we're progressing towards
> goals
> > such as Multi Product or a Responsive Layout over several versions.
> > Versions would clearly reflect what has been covered in each release, and
> > bugs can be raised against them.
> >
> > Longer term, with more contributors, we may get to a point where we're
> > able to complete one or more whole milestones within each release cycle.
> >
> > I'm sure we will come across situations where we need to make exceptions
> > to this process, but please provide feedback on whether the plan itself
> is
> > sound, not the possible exceptions.
> >
> > Cheers,
> > Joe
>
Re: [Proposal] New release process
Posted by Greg Stein <gs...@gmail.com>.
Too much process. Just make a release every N weeks. If something is done,
then it gets in. If not, then maybe it gets in the next release. Don't be
afraid to ship bugs because they will be fixed in two weeks in the next
release. This is not 1.0 -- there is no need to treat it with kid gloves.
Beat it up. If the release is total crap, then turn the crank and release
again a few days later.
Don't get so hung up on what is in/out. Just make releases. Continually and
repeatably.
The goal is activity, to build community.
There should be (IMO) goals about features at this point in time.
I disagree with the Eclipse numbering before 1.0. The project is not yet
managing feature releases. 0.2 then 0.3 ... Version numbers are cheap. Use
them.
Cheers,
-g
On Oct 8, 2012 5:16 AM, "Joachim Dreimann" <jo...@wandisco.com>
wrote:
> Hi everyone,
>
> I'd like to propose a new release process for releases after 0.2 (once
> accepted).
>
> Our current process (as I understand it):
> - A milestone containing tickets we believe should be fixed for the
> release is created.
> - Someone volunteers as release manager at an arbitrary point and packages
> up a release ready to be voted on.
> - All uncompleted tickets in the milestone are moved to the next upcoming
> milestone.
>
> In my opinion this is a messy process in which releases are unpredictable
> in scope and frequency.
>
> Proposed new process:
> 1. Monthly release cycle with the packages ready to be voted on during the
> first full week of the month.
> 2. Milestones are for meaningful goals we're working towards. For example:
> Multi product, Responsive Layout, etc
> 3. Versions are set up reflecting the priority Milestones for the next
> release. When the release is being packaged up, all tickets fixed since the
> last release are assigned to the Version.
>
> Obviously that would make the release frequency very predictable. I
> believe it also better reflects our actual working practice in the project
> better and make it easier for new contributors to pick up tickets.
> Meaningful Milestones allow us to track how we're progressing towards goals
> such as Multi Product or a Responsive Layout over several versions.
> Versions would clearly reflect what has been covered in each release, and
> bugs can be raised against them.
>
> Longer term, with more contributors, we may get to a point where we're
> able to complete one or more whole milestones within each release cycle.
>
> I'm sure we will come across situations where we need to make exceptions
> to this process, but please provide feedback on whether the plan itself is
> sound, not the possible exceptions.
>
> Cheers,
> Joe
Re: [Proposal] New release process
Posted by Peter Koželj <pe...@digiverse.si>.
Agree.
This will become even more evident when we move past Bloodhound 1.0
Personally I like what Eclipse is doing:
They have planned versions like 4.0, 4.1, 4.2... (new features) once per
year (it is a huge project).
They release every 6 weeks and that are called milestones: 4.1-M1,
4.1-M2... 4.1-RC, 4.1-Final
For us it could be monthly releases (milestones) with maybe 3 planned/road
mapped versions per year.
But I would not worry about it to much until we reach 1.0
Peter
On Mon, Oct 8, 2012 at 7:15 PM, Olemis Lang <ol...@gmail.com> wrote:
> On 10/8/12, Joachim Dreimann <jo...@wandisco.com> wrote:
> > Hi everyone,
> >
>
> :)
>
> > I'd like to propose a new release process for releases after 0.2 (once
> > accepted).
> >
> [...]
> >
> > In my opinion this is a messy process in which releases are
> unpredictable in
> > scope and frequency.
> >
> > Proposed new process:
> > 1. Monthly release cycle with the packages ready to be voted on during
> the
> > first full week of the month.
>
> +1 ... at least the idea sounds good to me . Nonetheless we should
> figure out some «recovery startegy» because nothing is perfect , and
> e.g. minor delays should be tolerated if there's a good reason for it
> to happen ... IMO
>
> > 2. Milestones are for meaningful goals we're working towards. For
> example:
> > Multi product, Responsive Layout, etc
>
> IMO the main reason for having milestones is to work towards a due
> date and provide value to the project as it evolves (e.g. release ,
> but maybe not the only goal ;) . What I notice regarding this aspect
> you mention is that your milestone will never end , so due date would
> be useless even if defined . The reason is that there are always
> enhancements , proposals , defects , ... related to features like
> those you mention above . Indeed it's possible to work on many tickets
> to deliver something at a given time , Release 1 is an example .
>
> > 3. Versions are set up reflecting the priority Milestones for the next
> > release. When the release is being packaged up, all tickets fixed since
> the
> > last release are assigned to the Version.
> >
>
> There are no meaningful versions defined in the issue tracker afaics .
> However my question is ... what is version ticket field for ? AFAICS
> there are two options .
>
> 1. Someone finds a bug or request for an enhancement and specifies
> the version considered as a starting point e.g. the version the user
> is running on some server out there ...
> 2. The target version in which work related to this ticket will be
> released
>
> > Obviously that would make the release frequency very predictable.
>
> IMO that will result in never-ending milestones . IMO they should
> represent project iterations instead .
>
> [...]
> >
> > Longer term, with more contributors, we may get to a point where we're
> able
> > to complete one or more whole milestones within each release cycle.
> >
>
> IMO in practice that will be pretty hard if using your model unless we
> are talking of trivial features , of course .
>
> [...]
> > but please provide feedback on whether the plan itself is
> > sound, not the possible exceptions.
> >
>
> my $0.02
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>
Re: [Proposal] New release process
Posted by Olemis Lang <ol...@gmail.com>.
On 10/8/12, Joachim Dreimann <jo...@wandisco.com> wrote:
> Hi everyone,
>
:)
> I'd like to propose a new release process for releases after 0.2 (once
> accepted).
>
[...]
>
> In my opinion this is a messy process in which releases are unpredictable in
> scope and frequency.
>
> Proposed new process:
> 1. Monthly release cycle with the packages ready to be voted on during the
> first full week of the month.
+1 ... at least the idea sounds good to me . Nonetheless we should
figure out some «recovery startegy» because nothing is perfect , and
e.g. minor delays should be tolerated if there's a good reason for it
to happen ... IMO
> 2. Milestones are for meaningful goals we're working towards. For example:
> Multi product, Responsive Layout, etc
IMO the main reason for having milestones is to work towards a due
date and provide value to the project as it evolves (e.g. release ,
but maybe not the only goal ;) . What I notice regarding this aspect
you mention is that your milestone will never end , so due date would
be useless even if defined . The reason is that there are always
enhancements , proposals , defects , ... related to features like
those you mention above . Indeed it's possible to work on many tickets
to deliver something at a given time , Release 1 is an example .
> 3. Versions are set up reflecting the priority Milestones for the next
> release. When the release is being packaged up, all tickets fixed since the
> last release are assigned to the Version.
>
There are no meaningful versions defined in the issue tracker afaics .
However my question is ... what is version ticket field for ? AFAICS
there are two options .
1. Someone finds a bug or request for an enhancement and specifies
the version considered as a starting point e.g. the version the user
is running on some server out there ...
2. The target version in which work related to this ticket will be released
> Obviously that would make the release frequency very predictable.
IMO that will result in never-ending milestones . IMO they should
represent project iterations instead .
[...]
>
> Longer term, with more contributors, we may get to a point where we're able
> to complete one or more whole milestones within each release cycle.
>
IMO in practice that will be pretty hard if using your model unless we
are talking of trivial features , of course .
[...]
> but please provide feedback on whether the plan itself is
> sound, not the possible exceptions.
>
my $0.02
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Proposal] New release process
Posted by Branko Čibej <br...@wandisco.com>.
On 08.10.2012 17:21, Gary Martin wrote:
> I can agree with the monthly release as a good idea in principle but I
> don't think that the meaningful milestones idea is that useful.
>
> I still want to see a milestone used to decide on a reasonable amount
> of work to do towards a given release. Feature development would
> essentially be cross milestone in this model. The component system may
> work well enough for that at the moment. The scope of the work
> expected for a given release is not made any more predictable by using
> milestones as cross-release categorisation.
>
> Personally I am hoping for a little more discipline from those who
> like to add more and more tickets to the active milestone.
No one should be bound by what's in an issue tracker (even if it's used
as a project planning tool). A release happens when the PMC decides one
is ready. Formal process is important for the release rollout itself;
anything else are just guidelines.
-- Brane
> On 08/10/12 13:15, Joachim Dreimann wrote:
>> Hi everyone,
>>
>> I'd like to propose a new release process for releases after 0.2
>> (once accepted).
>>
>> Our current process (as I understand it):
>> - A milestone containing tickets we believe should be fixed for the
>> release is created.
>> - Someone volunteers as release manager at an arbitrary point and
>> packages up a release ready to be voted on.
>> - All uncompleted tickets in the milestone are moved to the next
>> upcoming milestone.
>>
>> In my opinion this is a messy process in which releases are
>> unpredictable in scope and frequency.
>>
>> Proposed new process:
>> 1. Monthly release cycle with the packages ready to be voted on
>> during the first full week of the month.
>> 2. Milestones are for meaningful goals we're working towards. For
>> example: Multi product, Responsive Layout, etc
>> 3. Versions are set up reflecting the priority Milestones for the
>> next release. When the release is being packaged up, all tickets
>> fixed since the last release are assigned to the Version.
>>
>> Obviously that would make the release frequency very predictable. I
>> believe it also better reflects our actual working practice in the
>> project better and make it easier for new contributors to pick up
>> tickets. Meaningful Milestones allow us to track how we're
>> progressing towards goals such as Multi Product or a Responsive
>> Layout over several versions. Versions would clearly reflect what has
>> been covered in each release, and bugs can be raised against them.
>>
>> Longer term, with more contributors, we may get to a point where
>> we're able to complete one or more whole milestones within each
>> release cycle.
>>
>> I'm sure we will come across situations where we need to make
>> exceptions to this process, but please provide feedback on whether
>> the plan itself is sound, not the possible exceptions.
>>
>> Cheers,
>> Joe
>
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: [Proposal] New release process
Posted by Gary Martin <ga...@wandisco.com>.
I can agree with the monthly release as a good idea in principle but I
don't think that the meaningful milestones idea is that useful.
I still want to see a milestone used to decide on a reasonable amount of
work to do towards a given release. Feature development would
essentially be cross milestone in this model. The component system may
work well enough for that at the moment. The scope of the work expected
for a given release is not made any more predictable by using milestones
as cross-release categorisation.
Personally I am hoping for a little more discipline from those who like
to add more and more tickets to the active milestone.
Cheers,
Gary
On 08/10/12 13:15, Joachim Dreimann wrote:
> Hi everyone,
>
> I'd like to propose a new release process for releases after 0.2 (once accepted).
>
> Our current process (as I understand it):
> - A milestone containing tickets we believe should be fixed for the release is created.
> - Someone volunteers as release manager at an arbitrary point and packages up a release ready to be voted on.
> - All uncompleted tickets in the milestone are moved to the next upcoming milestone.
>
> In my opinion this is a messy process in which releases are unpredictable in scope and frequency.
>
> Proposed new process:
> 1. Monthly release cycle with the packages ready to be voted on during the first full week of the month.
> 2. Milestones are for meaningful goals we're working towards. For example: Multi product, Responsive Layout, etc
> 3. Versions are set up reflecting the priority Milestones for the next release. When the release is being packaged up, all tickets fixed since the last release are assigned to the Version.
>
> Obviously that would make the release frequency very predictable. I believe it also better reflects our actual working practice in the project better and make it easier for new contributors to pick up tickets. Meaningful Milestones allow us to track how we're progressing towards goals such as Multi Product or a Responsive Layout over several versions. Versions would clearly reflect what has been covered in each release, and bugs can be raised against them.
>
> Longer term, with more contributors, we may get to a point where we're able to complete one or more whole milestones within each release cycle.
>
> I'm sure we will come across situations where we need to make exceptions to this process, but please provide feedback on whether the plan itself is sound, not the possible exceptions.
>
> Cheers,
> Joe