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.
----- Original Message -----
From: "Brian Gupta"
Sent: Tuesday, January 22, 2013 9:34:56 AM
Subject: Re: [foreman-dev] A more formal release schedule
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?:
- These changes will allow us to get more features incorporated over the next year.
- No change
- 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.)
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 < email@example.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.