You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by David M Johnson <Da...@Sun.COM> on 2006/02/25 18:27:48 UTC
In search of a release cycle (was Re: VOTE: release Roller 2.1)
Comments below...
On Feb 25, 2006, at 12:20 AM, Henri Yandell wrote:
> On 2/24/06, Ted Husted <te...@gmail.com> wrote:
>> On 2/23/06, Henri Yandell <fl...@gmail.com> wrote:
>>> Personally, I think it gets silly to have to vote each time.
>
> The danger of a bombastic statement; everyone includes that one line
> in their replies and not the "however here's why we should" bit
> afterwards :)
>
>> Well, we really shouldn't cast a binding vote on a release until we
>> put into production ourselves. ("Eat our own dog food.") Since
>> this is
>> a new roll, we have to unroll it, put it up, and run the binary
>> through its paces. just to be certain all the bits are there.
>
> Biggest problem I find with that is that it means following tests
> aren't possible.
>
> If I migrated production from 2.0 to 2.1-rc1; my next install is
> 2.1-rc1 to 2.1-rc2 and not 2.0 to 2.1-rc2 at the database level. So I
> just run a test server until the real one is released.
>
> Dave, Elias and others work more at the bleeding edge; but that means
> their production servers tend to be on 2.1-pre-rc1 and that migration
> tends to kick off the release discussions. Unsure where Matt
> (JavaLobby) fits in on things release-wise.
I agree that's a problem with the milestone approach.
And I definitely agree that we need a more systematic approach to
making releases.
I don't have an answer, but maybe by sharing some information about
our development and deployment cycles we can find come common ground
here.
How often do customers and contributors like Javalobby, IBM and
others want to deploy new features?
At blogs.sun.com, we like to make changes in small, incremental, easy
to test and easy to document chunks. Allen and I make monthly
deployments like so:
a) Second to last Thursday of month - code freeze / deploy to
production
b) Last Thursday of month - deploy to production
Monthly works well for us (except for large features like group
blogging), but I've never thought that monthly Apache Roller release
make sense because other contributors don't have time to test every
month and I doubt customers want to upgrade on a monthly basis (or
the alternative, which is to fall behind).
- Dave
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Allen Gilliland <Al...@Sun.COM>.
that still sounds like a far more complex process than Roller needs.
I still support our current process where the community decides when
it's time to create a release and at the time we start the RC process.
-- Allen
Ted Husted wrote:
>On 2/25/06, Allen Gilliland <Al...@sun.com> wrote:
>
>
>>this sounds much more complicated to me. i prefer the RC approach that
>>we are using now.
>>
>>
>
>I'm probably not describing it well enough. Here's how HTTPD explains
>the system:
>
>* http://httpd.apache.org/dev/release.html
>
>-T.
>
>
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Ted Husted <te...@gmail.com>.
On 2/25/06, Allen Gilliland <Al...@sun.com> wrote:
> this sounds much more complicated to me. i prefer the RC approach that
> we are using now.
I'm probably not describing it well enough. Here's how HTTPD explains
the system:
* http://httpd.apache.org/dev/release.html
-T.
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Allen Gilliland <Al...@Sun.COM>.
Ted Husted wrote:
>On 2/25/06, Allen Gilliland <Al...@sun.com> wrote:
>
>
>> As Ted said, we should be
>>working to meet the needs of our frontline customers and I believe that
>>means blogs.sun.com followed by IBM, jRoller, and on.
>>
>>
>
>Customer is an interesting word when applied to an open source
>project. The dictionary definition is "One that buys goods or
>services", but the ASF isn't selling anything. All of our software is
>provided to the public at no charge.
>
>Looking beyond "buy", customers are the people who make the product
>possible. In the context of an open source project, the people who
>make the project possible are people like Dave, and Allen, and Avil,
>and Henri, and Matt, and all other other committers and contributors.
>
>Our customers are the people who provide patches and posts. Other
>people who simply download and use the software are *potential*
>customers (or "users"). From an ASF perspective, the core customer is
>the PMC.
>
>
I am new to the ASF so I apologize for my ignorance, but how is the PMC
our core customer? Who is the PMC you are talking about?
>Now, if it is important to Allen and Dave, two of our best customers,
>that Roller meet the needs of blogs.sun.com then it should be
>important to the rest of the community too. But, blogs.sun.com is only
>important because it is important to Allen and Dave. Sun cannot be a
>committer, and so Sun can never be a true customer. Only individuals
>can be committers, and ASF committer rights are *never* contingent on
>employment. If Sun hired another developer to work on Roller, that
>individual would have to earn his or her karma in the usual way.
>
>
that sounds right to me. Dave was basically the start of the community,
but I joined just like anyone else and if someone else from Sun wanted
to contribute they would go through the same process.
>The goal of an ASF project is to create the software that the members
>of the PMC want to use in their own projects. We do want to attract
>new users, because that's how we recruit new PMC members, but users
>are a means to an end.
>
>
at this point i am unsure of what this has to do with our release
process. i think we would all agree that our goal is to provide a
valuable product for the people who use Roller. i'm not sure i
understand exactly how the PMC fits into that, but in any case my only
goal is to provide quality blogging software. personally, my motives
are inspired by blogs.sun.com, but not limited to or entirely controlled
by blogs.sun.com.
-- Allen
>-Ted.
>
>
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Ted Husted <te...@gmail.com>.
On 2/25/06, Allen Gilliland <Al...@sun.com> wrote:
> As Ted said, we should be
> working to meet the needs of our frontline customers and I believe that
> means blogs.sun.com followed by IBM, jRoller, and on.
Customer is an interesting word when applied to an open source
project. The dictionary definition is "One that buys goods or
services", but the ASF isn't selling anything. All of our software is
provided to the public at no charge.
Looking beyond "buy", customers are the people who make the product
possible. In the context of an open source project, the people who
make the project possible are people like Dave, and Allen, and Avil,
and Henri, and Matt, and all other other committers and contributors.
Our customers are the people who provide patches and posts. Other
people who simply download and use the software are *potential*
customers (or "users"). From an ASF perspective, the core customer is
the PMC.
Now, if it is important to Allen and Dave, two of our best customers,
that Roller meet the needs of blogs.sun.com then it should be
important to the rest of the community too. But, blogs.sun.com is only
important because it is important to Allen and Dave. Sun cannot be a
committer, and so Sun can never be a true customer. Only individuals
can be committers, and ASF committer rights are *never* contingent on
employment. If Sun hired another developer to work on Roller, that
individual would have to earn his or her karma in the usual way.
The goal of an ASF project is to create the software that the members
of the PMC want to use in their own projects. We do want to attract
new users, because that's how we recruit new PMC members, but users
are a means to an end.
-Ted.
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Allen Gilliland <Al...@Sun.COM>.
Ted Husted wrote:
>On 2/26/06, David M Johnson <Da...@sun.com> wrote:
>
>
>>1) Release planning
>>- If you want to add a feature to a release, you assign it to
>>yourself and set the "fix-for" field for the release you want. (see
>>the roadmap view in JIRA).
>>
>>2) Development
>>- If you are working on a feature you mark it as "ongoing" in JIRA
>>
>>3) Monthly RC1: second to last thursday of each month
>>- If anybody thinks this month's changes warrant a release, they
>>ensure that user docs, install docs, change lists and database
>>scripts are updated and they create RC1.
>>
>>
>
>3) Monthly Milestone ... and they tag the repository for X_Y_# and
>create the X.Y.# build.
>
>3b) They also create a X_Y_#+1 release target in JIRA, and update the
>nightly build to reference X_Y_(#+1)-SNAPSHOT
>
>Meanwhile, mainline development continues in the trunk, and we mark
>issues "resolved" in X_Y_(#+1) as soon as the fix is committed, citing
>the SVN revision number for good measure.
>
>
my opinion is still that this sounds overly complex for Roller's
situation. i think our current system using release candidates is
working fine and doesn't need to change right now. maybe in the future
as the project continues to grow we will decide this milestone approach
is better, but for now I would say that I haven't seen a sufficient
reason to change our current system.
-- Allen
>
>
>
>>4) Test week
>>- Testing focuses on those features marked "ongoing" those that pass
>>testing are marked as "resolved"
>>
>>
>
>Testing focuses on those features marked as resolved in X_Y_#. If
>testing fails, the issue is reopened with an appropriate comment.
>
>
>
>>5) Monthly RC2: last thursday of each month
>>- If somebody rolled an RC last week and testing/fixing went well,
>>then they create a branch for the release, create RC2 from it and
>>call for a release vote. We iterate on RCs until voters are satisfied
>>- While that is happening, mainline development continues in the trunk
>>- Once release is made, the "resolved" issues are marked as "closed"
>>in JIRA
>>
>>
>
>If somebody rolled a Milestone last week, and testing/fixing went
>well, then they call for a quality vote on the milestone. If the vote
>comes back "GA", we update the website to announce a new "best
>available" release.
>
>If mainline development is ready to commence on to the next minor or
>major release, we tag and branch the current repository for
>"X_Y_BRANCH" and designate the HEAD X_Z or Y_A.
>
>-Ted.
>
>
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by David M Johnson <Da...@Sun.COM>.
I added a section called "The monthly release cycle" to the Roller
release plan document on the wiki with what I believe to be the
consensus on this issue.
http://rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan
Comments?
- Dave
On Feb 27, 2006, at 1:04 PM, Matt Raible wrote:
> On 2/27/06, David M Johnson <Da...@sun.com> wrote:
>>
>> On Feb 26, 2006, at 12:17 PM, Ted Husted wrote:
>>> On 2/26/06, David M Johnson <Da...@sun.com> wrote:
>>>> 3) Monthly RC1: second to last thursday of each month
>>>> - If anybody thinks this month's changes warrant a release, they
>>>> ensure that user docs, install docs, change lists and database
>>>> scripts are updated and they create RC1.
>>>
>>> 3) Monthly Milestone ... and they tag the repository for X_Y_# and
>>> create the X.Y.# build.
>>>
>>> 3b) They also create a X_Y_#+1 release target in JIRA, and
>>> update the
>>> nightly build to reference X_Y_(#+1)-SNAPSHOT
>>>
>>> Meanwhile, mainline development continues in the trunk, and we mark
>>> issues "resolved" in X_Y_(#+1) as soon as the fix is committed,
>>> citing
>>> the SVN revision number for good measure.
>>
>>
>> I understand now how this could work for us, but I guess I don't see
>> a good reason to change and it does seem more complex. Nobody has
>> spoken up on the cycle other than Ted, Allen and I have responded
>> about the release cycle. This could mean that folks are happy with
>> release cycle as is.
>
> I'm happy with it - but I also pull all my releases from SVN. In
> addition, when I have someone else install Roller - I wait for a
> release, not an RC.
>
>>
>> The repeat voting and "are we there yet" queries were irritating (and
>> my fault). I think the main problem with the voting has been that I
>> called for votes too early. We need to release an RC or two, get
>> positive feedback/testing and only call for a vote when it appears
>> that a vote can be won. Otherwise we get in a cycle.
>
> Release candidates are good - but you could also do a "pull from SVN
> when you get a chance". It's less formal, but would likely achieve
> the same results.
>
>>
>> Anybody else want to comment on the de facto release cycle that I
>> documented in the previous email?
>
> As a release manager on other projects, having a consistent release
> process is important if you plan on handing it off to someone.
> Otherwise, I'd recommend keeping your current system. That being
> said, it might be a good idea to hand it off to someone. ;-) Getting
> volunteers is the hard part.
>
> Matt
>
>>
>> - Dave
>>
>>
>>
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Matt Raible <mr...@gmail.com>.
On 2/27/06, David M Johnson <Da...@sun.com> wrote:
>
> On Feb 26, 2006, at 12:17 PM, Ted Husted wrote:
> > On 2/26/06, David M Johnson <Da...@sun.com> wrote:
> >> 3) Monthly RC1: second to last thursday of each month
> >> - If anybody thinks this month's changes warrant a release, they
> >> ensure that user docs, install docs, change lists and database
> >> scripts are updated and they create RC1.
> >
> > 3) Monthly Milestone ... and they tag the repository for X_Y_# and
> > create the X.Y.# build.
> >
> > 3b) They also create a X_Y_#+1 release target in JIRA, and update the
> > nightly build to reference X_Y_(#+1)-SNAPSHOT
> >
> > Meanwhile, mainline development continues in the trunk, and we mark
> > issues "resolved" in X_Y_(#+1) as soon as the fix is committed, citing
> > the SVN revision number for good measure.
>
>
> I understand now how this could work for us, but I guess I don't see
> a good reason to change and it does seem more complex. Nobody has
> spoken up on the cycle other than Ted, Allen and I have responded
> about the release cycle. This could mean that folks are happy with
> release cycle as is.
I'm happy with it - but I also pull all my releases from SVN. In
addition, when I have someone else install Roller - I wait for a
release, not an RC.
>
> The repeat voting and "are we there yet" queries were irritating (and
> my fault). I think the main problem with the voting has been that I
> called for votes too early. We need to release an RC or two, get
> positive feedback/testing and only call for a vote when it appears
> that a vote can be won. Otherwise we get in a cycle.
Release candidates are good - but you could also do a "pull from SVN
when you get a chance". It's less formal, but would likely achieve
the same results.
>
> Anybody else want to comment on the de facto release cycle that I
> documented in the previous email?
As a release manager on other projects, having a consistent release
process is important if you plan on handing it off to someone.
Otherwise, I'd recommend keeping your current system. That being
said, it might be a good idea to hand it off to someone. ;-) Getting
volunteers is the hard part.
Matt
>
> - Dave
>
>
>
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by David M Johnson <Da...@Sun.COM>.
On Feb 26, 2006, at 12:17 PM, Ted Husted wrote:
> On 2/26/06, David M Johnson <Da...@sun.com> wrote:
>> 3) Monthly RC1: second to last thursday of each month
>> - If anybody thinks this month's changes warrant a release, they
>> ensure that user docs, install docs, change lists and database
>> scripts are updated and they create RC1.
>
> 3) Monthly Milestone ... and they tag the repository for X_Y_# and
> create the X.Y.# build.
>
> 3b) They also create a X_Y_#+1 release target in JIRA, and update the
> nightly build to reference X_Y_(#+1)-SNAPSHOT
>
> Meanwhile, mainline development continues in the trunk, and we mark
> issues "resolved" in X_Y_(#+1) as soon as the fix is committed, citing
> the SVN revision number for good measure.
I understand now how this could work for us, but I guess I don't see
a good reason to change and it does seem more complex. Nobody has
spoken up on the cycle other than Ted, Allen and I have responded
about the release cycle. This could mean that folks are happy with
release cycle as is.
The repeat voting and "are we there yet" queries were irritating (and
my fault). I think the main problem with the voting has been that I
called for votes too early. We need to release an RC or two, get
positive feedback/testing and only call for a vote when it appears
that a vote can be won. Otherwise we get in a cycle.
Anybody else want to comment on the de facto release cycle that I
documented in the previous email?
- Dave
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Ted Husted <te...@gmail.com>.
On 2/26/06, David M Johnson <Da...@sun.com> wrote:
> 1) Release planning
> - If you want to add a feature to a release, you assign it to
> yourself and set the "fix-for" field for the release you want. (see
> the roadmap view in JIRA).
>
> 2) Development
> - If you are working on a feature you mark it as "ongoing" in JIRA
>
> 3) Monthly RC1: second to last thursday of each month
> - If anybody thinks this month's changes warrant a release, they
> ensure that user docs, install docs, change lists and database
> scripts are updated and they create RC1.
3) Monthly Milestone ... and they tag the repository for X_Y_# and
create the X.Y.# build.
3b) They also create a X_Y_#+1 release target in JIRA, and update the
nightly build to reference X_Y_(#+1)-SNAPSHOT
Meanwhile, mainline development continues in the trunk, and we mark
issues "resolved" in X_Y_(#+1) as soon as the fix is committed, citing
the SVN revision number for good measure.
> 4) Test week
> - Testing focuses on those features marked "ongoing" those that pass
> testing are marked as "resolved"
Testing focuses on those features marked as resolved in X_Y_#. If
testing fails, the issue is reopened with an appropriate comment.
> 5) Monthly RC2: last thursday of each month
> - If somebody rolled an RC last week and testing/fixing went well,
> then they create a branch for the release, create RC2 from it and
> call for a release vote. We iterate on RCs until voters are satisfied
> - While that is happening, mainline development continues in the trunk
> - Once release is made, the "resolved" issues are marked as "closed"
> in JIRA
If somebody rolled a Milestone last week, and testing/fixing went
well, then they call for a quality vote on the milestone. If the vote
comes back "GA", we update the website to announce a new "best
available" release.
If mainline development is ready to commence on to the next minor or
major release, we tag and branch the current repository for
"X_Y_BRANCH" and designate the HEAD X_Z or Y_A.
-Ted.
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Allen Gilliland <Al...@Sun.COM>.
Ted Husted wrote:
>On 2/25/06, David M Johnson <Da...@sun.com> wrote:
>
>
>>I agree that's a problem with the milestone approach.
>>
>>
>
>I'm not seeing the problem. Could someone explain it again in different terms?
>
>The only real difference is that instead of making a predetermination
>that a build will NOT be a release, but only a release candidate, we
>wait and make the determination after it is released. This simplifies
>the nomenclature and reduces the work of recasting the final release
>candidate as the final release. We just announce that a certain
>milestone is ready for primetime.
>
>As for things like database upgrade scripts, once a milestone runs,
>the scripts are frozen in the distribution, we can just rename the
>script for the next milestone. So the 2.0-2.1.4 script becomes the
>2.0-2.1.5 script. And with SVN, we can actually rename the file!
>
>Teams like HTTPD, Tomcat, Struts, and MyFaces have been using this
>scheme for a long time, and it seems to work well. Once the 2.1.4
>milestone is rolled, the nightly build becomes the 2.1.5-SNAPSHOT, so
>there is no ambiguity about what comes next.
>
>
>
this sounds much more complicated to me. i prefer the RC approach that
we are using now.
>
>
>>And I definitely agree that we need a more systematic approach to
>>making releases.
>>
>>I don't have an answer, but maybe by sharing some information about
>>our development and deployment cycles we can find come common ground
>>here.
>>
>>How often do customers and contributors like Javalobby, IBM and
>>others want to deploy new features?
>>
>>
>
>With the milestone approach, people have the option. It's not uncommon
>for there to be several GA releases with in the same version series.
>If the changes to 2.1.5 are not compelling, they can wait until
>another milestone, and jump in at say, 2.1.12.
>
>Whether a milestone contains only bugfixes or includes new
>backwardly-compatible features is something people can decide in a
>release plan for each milestone. We've been using a checklist format
>for the Struts release plans, which seems to be working well.
>
>* http://wiki.apache.org/struts/StrutsRelease128
>
>
again, sounds overly complicated to me. i think our current release
conventions are fine.
>
>
>
>>At blogs.sun.com, we like to make changes in small, incremental, easy
>>to test and easy to document chunks. Allen and I make monthly
>>deployments like so:
>> a) Second to last Thursday of month - code freeze / deploy to
>>production
>> b) Last Thursday of month - deploy to production
>>
>>Monthly works well for us (except for large feautures like group
>>blogging), but I've never thought that monthly Apache Rollerser release
>>make sense because other contributors don't have time to test every
>>month and I doubt customers want to upgrade on a monthly basis (or
>>the alternative, which is to fall behind).
>>
>>
>
>Oh, people always fall behind. Struts has a 18-month release cycle,
>and we still have a lot of people who want to migrate from 1.0 to 1.2,
>or from 1.1 to 1.3, or from 1.0 to 1.3.The curse of distributing
>reliable high-quality software is that makes it easier for users to
>stay the course!
>
>The important thing is that we have a release process that suits our
>core customers: the Roller PMC. It's nice that other people use our
>software, and hopefully some of these people will become contributors
>and committers, but the people we need to please first are the
>frontline volunteers who make the software possible.
>
>
i think we should release as fast as the developers are willing and able
to. this may sound a bit bastardly, but who cares if customers don't
want to keep up with our release pace? that's their problem, not ours.
as Dave said, at Sun we are doing monthly releases and I believe we are
delivering enough code in each month to warrant a new release. we also
test each release on blogs.sun.com before calling for a Roller release,
so i think that is plenty of "production" testing. i don't see any
reason not to do a Roller release each month if we are delivering
valuable new code which is production tested. As Ted said, we should be
working to meet the needs of our frontline customers and I believe that
means blogs.sun.com followed by IBM, jRoller, and on.
speaking more generally, i think the longer the development cycle the
harder we make things on ourselves, so i have always advocated for short
and compact release cycles. also note that short doesn't mean short
time, it means short on code. if we are delivering valuable and well
tested code every 2 weeks then lets release every 2 weeks, if it's once
a month then lets release once a month, and if its once every 2-3 months
then we should release then. so to make my point as blatenly obvious
and repetative as possible, i think we should be doing releases based on
how often we are delivering valuable new code that has been properly
tested. IMO we are doing that once a month, so i vote for monthly releases.
-- Allen
>-Ted.
>
>
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Ted Husted <te...@gmail.com>.
On 2/26/06, David M Johnson <Da...@sun.com> wrote:
> Milestones
> May - Roller X.Y.1 good release, voted up to GA status
> June - Roller X.Y.2 not so good, just considered a alpha
> July - Roller X.Y.3 not so good, just considered a beta
> August - Roller X.Y.4 good release, voted up to GA status
>
> A user upgrading from X.Y.1 to X.Y.4 needs to incorporate database
> schema changes that were made in releases that never got the
> official seal of approval. Isn't that a problem?
Not that I can see. Each of these distributions would have contained
the scripts current to that build. The user would just use whatever
script came in the distribution.
By the time we got to
* September - Roller X.Y.5
usually, we would already know if X.Y.4 made the grade or not.
* If not, we could rename X.W-to-X.Y.4 to X.W-to-X.Y.5.
* If it did go GA, and the database changes continued, we could just
start a new X.Y.4-to-X.Y.5 file.
One of the reasons that HTTPD started to use this scheme is because it
lessens the need to freeze the codebase. Each milestone is a snapshot,
we roll the milestone, and we get back to work on the next milestone.
-Ted.
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by David M Johnson <Da...@Sun.COM>.
On Feb 25, 2006, at 9:42 PM, Ted Husted wrote:
> On 2/25/06, David M Johnson <Da...@sun.com> wrote:
>> I agree that's a problem with the milestone approach.
>
> I'm not seeing the problem. Could someone explain it again in
> different terms?
I think the problem is this. Each monthly release adds new features
and usually database schema changes. If each month's release is just
a milestone that may or may not be voted as an official "GA" release
then users will miss important database changes.
Milestones
May - Roller X.Y.1 good release, voted up to GA status
June - Roller X.Y.2 not so good, just considered a alpha
July - Roller X.Y.3 not so good, just considered a beta
August - Roller X.Y.4 good release, voted up to GA status
A user upgrading from X.Y.1 to X.Y.4 needs to incorporate database
schema changes that were made in releases that never got the
official seal of approval. Isn't that a problem?
Maybe we're not in search of a release cycle. Maybe the one we have
is fine. Here's the release cycle that has been in-effect recently
(i.e. this is what Allen and I have been doing).
1) Release planning
- If you want to add a feature to a release, you assign it to
yourself and set the "fix-for" field for the release you want. (see
the roadmap view in JIRA).
2) Development
- If you are working on a feature you mark it as "ongoing" in JIRA
3) Monthly RC1: second to last thursday of each month
- If anybody thinks this month's changes warrant a release, they
ensure that user docs, install docs, change lists and database
scripts are updated and they create RC1.
4) Test week
- Testing focuses on those features marked "ongoing" those that pass
testing are marked as "resolved"
5) Monthly RC2: last thursday of each month
- If somebody rolled an RC last week and testing/fixing went well,
then they create a branch for the release, create RC2 from it and
call for a release vote. We iterate on RCs until voters are satisfied
- While that is happening, mainline development continues in the trunk
- Once release is made, the "resolved" issues are marked as "closed"
in JIRA
- Dave
Re: In search of a release cycle (was Re: VOTE: release Roller 2.1)
Posted by Ted Husted <te...@gmail.com>.
On 2/25/06, David M Johnson <Da...@sun.com> wrote:
> I agree that's a problem with the milestone approach.
I'm not seeing the problem. Could someone explain it again in different terms?
The only real difference is that instead of making a predetermination
that a build will NOT be a release, but only a release candidate, we
wait and make the determination after it is released. This simplifies
the nomenclature and reduces the work of recasting the final release
candidate as the final release. We just announce that a certain
milestone is ready for primetime.
As for things like database upgrade scripts, once a milestone runs,
the scripts are frozen in the distribution, we can just rename the
script for the next milestone. So the 2.0-2.1.4 script becomes the
2.0-2.1.5 script. And with SVN, we can actually rename the file!
Teams like HTTPD, Tomcat, Struts, and MyFaces have been using this
scheme for a long time, and it seems to work well. Once the 2.1.4
milestone is rolled, the nightly build becomes the 2.1.5-SNAPSHOT, so
there is no ambiguity about what comes next.
> And I definitely agree that we need a more systematic approach to
> making releases.
>
> I don't have an answer, but maybe by sharing some information about
> our development and deployment cycles we can find come common ground
> here.
>
> How often do customers and contributors like Javalobby, IBM and
> others want to deploy new features?
With the milestone approach, people have the option. It's not uncommon
for there to be several GA releases with in the same version series.
If the changes to 2.1.5 are not compelling, they can wait until
another milestone, and jump in at say, 2.1.12.
Whether a milestone contains only bugfixes or includes new
backwardly-compatible features is something people can decide in a
release plan for each milestone. We've been using a checklist format
for the Struts release plans, which seems to be working well.
* http://wiki.apache.org/struts/StrutsRelease128
> At blogs.sun.com, we like to make changes in small, incremental, easy
> to test and easy to document chunks. Allen and I make monthly
> deployments like so:
> a) Second to last Thursday of month - code freeze / deploy to
> production
> b) Last Thursday of month - deploy to production
>
> Monthly works well for us (except for large feautures like group
> blogging), but I've never thought that monthly Apache Rollerser release
> make sense because other contributors don't have time to test every
> month and I doubt customers want to upgrade on a monthly basis (or
> the alternative, which is to fall behind).
Oh, people always fall behind. Struts has a 18-month release cycle,
and we still have a lot of people who want to migrate from 1.0 to 1.2,
or from 1.1 to 1.3, or from 1.0 to 1.3.The curse of distributing
reliable high-quality software is that makes it easier for users to
stay the course!
The important thing is that we have a release process that suits our
core customers: the Roller PMC. It's nice that other people use our
software, and hopefully some of these people will become contributors
and committers, but the people we need to please first are the
frontline volunteers who make the software possible.
-Ted.