A more formal release schedule

The time between the release of 1.0 and 1.1 has been pretty long and there seems to be general agreement that we should adopt a more formally scheduled release cycle. The initial suggestion was to release quarterly, which would be about half the time between 1.0 and 1.1 - how do people feel about that?

Another important consideration is when to start the RC cycle. I think cutting the first RC tag after 2 months of development (assuming a 3 month cycle) and then releasing a new RC every week is a good amount of time to get users on the RC and to merge bug fixes. That would mean 4 RC releases, while we are currently expecting to have 5 for 1.1.

Just a few different ideas to start the conversation.

-Sam

Topic for roadmap meeting?

··· On Jan 17, 2013 8:07 PM, "Sam Kottler" wrote:

The time between the release of 1.0 and 1.1 has been pretty long and there
seems to be general agreement that we should adopt a more formally
scheduled release cycle. The initial suggestion was to release quarterly,
which would be about half the time between 1.0 and 1.1 - how do people feel
about that?

Another important consideration is when to start the RC cycle. I think
cutting the first RC tag after 2 months of development (assuming a 3 month
cycle) and then releasing a new RC every week is a good amount of time to
get users on the RC and to merge bug fixes. That would mean 4 RC releases,
while we are currently expecting to have 5 for 1.1.

Just a few different ideas to start the conversation.

-Sam

Be aware that planning is nearly always different from reality.

So if you plan release after 3 months, it will be usually 3.5-5 months.

I suggest you to plan release every 2 months with actually release every
2.5-3 months.
:slight_smile:

··· On 01/18/2013 02:07 AM, Sam Kottler wrote: > The time between the release of 1.0 and 1.1 has been pretty long and there seems to be general agreement that we should adopt a more formally scheduled release cycle. The initial suggestion was to release quarterly, which would be about half the time between 1.0 and 1.1 - how do people feel about that?


Miroslav Suchy
Red Hat Systems Management Engineering

Sure, but this might be a little different from the general goal of the roadmap meeting.

··· ----- Original Message ----- From: "Brian Gupta" To: "foreman-dev" Sent: Thursday, January 17, 2013 11:10:36 PM Subject: Re: [foreman-dev] A more formal release schedule

Topic for roadmap meeting?
On Jan 17, 2013 8:07 PM, “Sam Kottler” < skottler@redhat.com > wrote:

The time between the release of 1.0 and 1.1 has been pretty long and there seems to be general agreement that we should adopt a more formally scheduled release cycle. The initial suggestion was to release quarterly, which would be about half the time between 1.0 and 1.1 - how do people feel about that?

Another important consideration is when to start the RC cycle. I think cutting the first RC tag after 2 months of development (assuming a 3 month cycle) and then releasing a new RC every week is a good amount of time to get users on the RC and to merge bug fixes. That would mean 4 RC releases, while we are currently expecting to have 5 for 1.1.

Just a few different ideas to start the conversation.

-Sam

Ok in that case, I have mixed feelings about a formal release schedule, as
I do think we need to maintain flexibility to incorporate "big" changes. If
we had been on a quarterly release schedule, I am not sure some of the
historical big changes like switching from Rails 2 -> Rails 3 could have
been incorporated. That said quarterly releases might be a good target, but
I think we should be careful about trying to set this in stone.

I would propose that we have a "roadmap/planning meeting" after every
release, to set our high level goals for the next release, and based on
that, also set a target date for the next release, which should be the
target for cutting the first RC release. (Not the final shipping release.)
We ship final after we make it through the RC process when all is good.

Please also bear in mind that based on our last roadmap meeting, changes in
process, and release schedules were definitely on topic, and I would really
consider the roadmap meetings also a dev planning meeting.

Thanks,
Brian

··· On Fri, Jan 18, 2013 at 9:50 AM, Sam Kottler wrote:

Sure, but this might be a little different from the general goal of the
roadmap meeting.

----- Original Message -----
From: “Brian Gupta” brian.gupta@brandorr.com
To: “foreman-dev” foreman-dev@googlegroups.com
Sent: Thursday, January 17, 2013 11:10:36 PM
Subject: Re: [foreman-dev] A more formal release schedule

Topic for roadmap meeting?
On Jan 17, 2013 8:07 PM, “Sam Kottler” < skottler@redhat.com > wrote:

The time between the release of 1.0 and 1.1 has been pretty long and there
seems to be general agreement that we should adopt a more formally
scheduled release cycle. The initial suggestion was to release quarterly,
which would be about half the time between 1.0 and 1.1 - how do people feel
about that?

Another important consideration is when to start the RC cycle. I think
cutting the first RC tag after 2 months of development (assuming a 3 month
cycle) and then releasing a new RC every week is a good amount of time to
get users on the RC and to merge bug fixes. That would mean 4 RC releases,
while we are currently expecting to have 5 for 1.1.

Just a few different ideas to start the conversation.

-Sam


http://aws.amazon.com/solutions/solution-providers/brandorr/

Let's put this on the meeting agenda, by all means, but for the record
here's my thoughts.

My main concern is how we handle a release. Historically, we've merged new
things into Develop as they become ready, even if we're sitting at (say)
RC4. This means new code is getting less testing than it should - we have
features which are only really going through one RC before release. It also
massively extends the RC period, as new bugs come up from code merged in a
later RC, meaning more RCs are needed. As each RC seems to have a lifecycle
of about 2 weeks, it can take many months to finish a release.

The reason this happens is because we do so few releases (we're averaging 1
a year). That makes us keen to merge new feature in that people are waiting
for, and tempts us into cutting corners elsewhere. By releasing more
regularly, people know they don't have to wait too long for new features,
and takes the pressure of us to cram so much into each release. We can then
use a more formal approach in which we cut a branch at the start of the
first RC and only merge bugfixes to that branch thereafter.

Brian, you make a good point about complex features/changes, but these can
be in development across multiple releases if need be. Managing a
feature-branch which tracks Develop is the standard way of working with
Git, and when it's ready it will slot into the next release. Something like
a Rail change might well generate more RCs than normal, since it's such a
widespread change, but there are methods of coping with that (for example,
see what Puppetlabs call "The Thunderdome" - not that I'm suggesting we
adopt it, merely an example).

All in all, I think a more regular release cycle will take the pressure of
us to cram everything possible into each release, and allow us to merge
things when they're done.

Greg

Greg/Sam,

So, I've given this a lot of thought and have one question for both Sam and
you. Assuming we make the changes to the development process that you want,
and assuming no changes in available developer manhours, how would this
impact the project going out one year?:

  1. These changes will allow us to get more features incorporated over the
    next year.
  2. No change
  3. This will require most developer man hours to facilitate and we will get
    fewer changes incorporated over the next year.

BTW - I do understand at some point, that we will need to move to a more
formal dev methodology. I am just not sure if we are there yet. I would
think that we can get behind planning for more frequent releases though,
but I sense moving from 1 major release per year to 4 might be a challenge,
and would put us pretty much into a rolling release workflow. IE: You guys
would be spending most of your time doing releases.)

I've also heard that we release once a year, and also heard that between
1.0 and 1.1 was about six months. So if we kept the current release cadence
we are looking at 2 releases per year, which I think is sustainable with
current manpower. Later as the team grows, and/or the pressure to add new
features lessens, I think we can make the changes you guys suggest, it's
just a mater of when do we want to implement them.

(I would say that we should probably look to quarterly roadmap/devplanning
meetings as a first step, in any case.)

Thanks,
Brian

P.S. - Please be reminded that our current codebase gets more testing than
it ever did in the past due to all the automated testing you guys have
added.

··· On Mon, Jan 21, 2013 at 6:08 AM, Greg Sutcliffe wrote:

Let’s put this on the meeting agenda, by all means, but for the record
here’s my thoughts.

My main concern is how we handle a release. Historically, we’ve merged new
things into Develop as they become ready, even if we’re sitting at (say)
RC4. This means new code is getting less testing than it should - we have
features which are only really going through one RC before release. It also
massively extends the RC period, as new bugs come up from code merged in a
later RC, meaning more RCs are needed. As each RC seems to have a lifecycle
of about 2 weeks, it can take many months to finish a release.

The reason this happens is because we do so few releases (we’re averaging
1 a year). That makes us keen to merge new feature in that people are
waiting for, and tempts us into cutting corners elsewhere. By releasing
more regularly, people know they don’t have to wait too long for new
features, and takes the pressure of us to cram so much into each release.
We can then use a more formal approach in which we cut a branch at the
start of the first RC and only merge bugfixes to that branch thereafter.

Brian, you make a good point about complex features/changes, but these can
be in development across multiple releases if need be. Managing a
feature-branch which tracks Develop is the standard way of working with
Git, and when it’s ready it will slot into the next release. Something like
a Rail change might well generate more RCs than normal, since it’s such a
widespread change, but there are methods of coping with that (for example,
see what Puppetlabs call “The Thunderdome” - not that I’m suggesting we
adopt it, merely an example).

All in all, I think a more regular release cycle will take the pressure of
us to cram everything possible into each release, and allow us to merge
things when they’re done.

Greg


http://aws.amazon.com/solutions/solution-providers/brandorr/

Sorry I let this thread go for a few days.

1.0 was released a little over 6 months ago. Since then we've added parameterized classes, locations & orgs, puppet 3 & ruby 1.9.3 support, plus lots of other good stuff. The problem with such a long release cycle is that there are some users who have requirements inside of their companies/organizations that they can't deploy code that isn't marked as "stable" in a purely semantic sense. That means that there are users who don't get to have any of the above features until we do a formal release. Another class of users with the same problem is people who want to use Foreman, but don't want to track development very closely; the stable releases are a perfect fit for people who want "set it and forget it" ease to their installations.

As for the actual release cycle, I think we can set a shorter target and then discuss the actual date as development progresses. Of course, if there were still bugs and issues, we wouldn't just do a release because that day was the last of the quarter. As for fitting features into the release cycle: there are very few features that take that long to integrate and iterate on. Orgs/locations is the only one I can think of that was too involved to fit into a 3 month process.

-Sam

··· ----- Original Message ----- From: "Brian Gupta" To: foreman-dev@googlegroups.com Sent: Tuesday, January 22, 2013 9:34:56 AM Subject: Re: [foreman-dev] A more formal release schedule

Greg/Sam,

So, I’ve given this a lot of thought and have one question for both Sam and you. Assuming we make the changes to the development process that you want, and assuming no changes in available developer manhours, how would this impact the project going out one year?:

  1. These changes will allow us to get more features incorporated over the next year.
  2. No change
  3. This will require most developer man hours to facilitate and we will get fewer changes incorporated over the next year.

BTW - I do understand at some point, that we will need to move to a more formal dev methodology. I am just not sure if we are there yet. I would think that we can get behind planning for more frequent releases though, but I sense moving from 1 major release per year to 4 might be a challenge, and would put us pretty much into a rolling release workflow. IE: You guys would be spending most of your time doing releases.)

I’ve also heard that we release once a year, and also heard that between 1.0 and 1.1 was about six months. So if we kept the current release cadence we are looking at 2 releases per year, which I think is sustainable with current manpower. Later as the team grows, and/or the pressure to add new features lessens, I think we can make the changes you guys suggest, it’s just a mater of when do we want to implement them.

(I would say that we should probably look to quarterly roadmap/devplanning meetings as a first step, in any case.)

Thanks,
Brian

P.S. - Please be reminded that our current codebase gets more testing than it ever did in the past due to all the automated testing you guys have added.

On Mon, Jan 21, 2013 at 6:08 AM, Greg Sutcliffe < greg.sutcliffe@gmail.com > wrote:

Let’s put this on the meeting agenda, by all means, but for the record here’s my thoughts.

My main concern is how we handle a release. Historically, we’ve merged new things into Develop as they become ready, even if we’re sitting at (say) RC4. This means new code is getting less testing than it should - we have features which are only really going through one RC before release. It also massively extends the RC period, as new bugs come up from code merged in a later RC, meaning more RCs are needed. As each RC seems to have a lifecycle of about 2 weeks, it can take many months to finish a release.

The reason this happens is because we do so few releases (we’re averaging 1 a year). That makes us keen to merge new feature in that people are waiting for, and tempts us into cutting corners elsewhere. By releasing more regularly, people know they don’t have to wait too long for new features, and takes the pressure of us to cram so much into each release. We can then use a more formal approach in which we cut a branch at the start of the first RC and only merge bugfixes to that branch thereafter.

Brian, you make a good point about complex features/changes, but these can be in development across multiple releases if need be. Managing a feature-branch which tracks Develop is the standard way of working with Git, and when it’s ready it will slot into the next release. Something like a Rail change might well generate more RCs than normal, since it’s such a widespread change, but there are methods of coping with that (for example, see what Puppetlabs call “The Thunderdome” - not that I’m suggesting we adopt it, merely an example).

All in all, I think a more regular release cycle will take the pressure of us to cram everything possible into each release, and allow us to merge things when they’re done.

Greg