Proposal for radically altered approach to releases

[Beman Dawes]

The current approach to getting releases ready is completely broken in
my opinion. Each release requires heroic efforts by the release manager,
careful attention by many developers, and endless delays until
everything is just right.

This is discouraging to developers and, worse yet, important library
upgrades and bug fixes are taking far too long to get into user's hands.

The problems with the current release approach are not caused by release
managers or developers, but rather by the release system itself. It just
doesn't scale up to the number of libraries now in Boost, since every
library has to be ready before a release can occur.

These problems will only grow worse as more libraries are added.

I propose changing to a different release model, one based on always
maintaining a release-ready stable branch and merging updates for
individual libraries into it asynchronously.

A draft proposal is available at
http://mysite.verizon.net/beman/release_overview.html.

I've put a fair amount of thought into this proposal, and have run some
Subversion simulations to make sure it works smoothly.

What do others think?

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Michael Fawcett]

On 5/11/06, Beman Dawes <bdawes@...> wrote:

<pasted from proposal>

> We might say Sunday and Monday are merge days, Tuesday through Friday are test days, > and Saturday is tag day. Since it is possible to automatically tell if unexpected failures have > occurred, tagging can be by automatically scheduled script.

I know you were using a simplified example and you probably had
something more concrete in mind, but do consider everyone's varying
timezones (you probably did, or have a solution that makes the point
moot).  Perhaps a SVN script that freezes stable during certain hours
so that merges can't occur.  Then developers don't have to check some
schedule online and do the time conversion themselves.

--Michael Fawcett
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Simon Carter-2]

Beman Dawes <bdawes <at> acm.org> writes:
>
> http://mysite.verizon.net/beman/release_overview.html.
>
The link is broken for me.

I don't mind how the release is managed so long as I can use some kind of
numbering system to completely identify the version of boost I have. As a
minimum the overall boost version number should be incremented everytime
anything in the release branch changes.

I'm thinking of cases where I know my app worked with (say) boost 1_30_0 but not
with 1_32_0 - I need to be able to go back to the earlier version without
jumping through hoops to reconstruct the state of the release branch at a
particular point in time.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Arkadiy Vertleyb]

"Beman Dawes" <bdawes@...> wrote

> The problems with the current release approach are not caused by release
> managers or developers, but rather by the release system itself. It just
> doesn't scale up to the number of libraries now in Boost, since every
> library has to be ready before a release can occur.
>
> These problems will only grow worse as more libraries are added.

I think you are considering just one dimension of the problem.

The other one -- the number of supported compilers is IMO equaly, if not
even more, important.  The broken build can be detected only after the
regressions run on all the compilers.  Which may be a few days (or a few
weeks).  To fix the build would require a few more regression cycles, and by
that time new errors can (and most likely will) be introduced.

Something needs to be done about compiler availability -- this is the most
critical issue, IMO.

Regards,
Arkadiy



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Pedro Lamarão]

Beman Dawes escreveu:

> I've put a fair amount of thought into this proposal, and have run some
> Subversion simulations to make sure it works smoothly.
>
> What do others think?

Here:

"Formal releases occur on a regular schedule. The formal release
procedure is simply to package up the last tagged revision of stable,
publish release candidates, and decide if there are any issues serious
enough to wait for the next stable tag point."

If this process would contemplate a bugfix branches associated with
stable tags, and if some backporting fixes effort were made, the people
complaining about API stability would be happier.

No need to bugfix for ever; maybe just the previous release; or whatever
is confortable enough. This should just give more longevity, and a
healthier old age, to each Boost release.

--
Pedro Lamarão
Desenvolvimento

Intersix Technologies S.A.
SP: (55 11 3803-9300)
RJ: (55 21 3852-3240)
www.intersix.com.br

Your Security is our Business

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Robert Ramey]

This is on the right track.


Not too long ago we had a discussion of this very topic
a few months ago.

see http://lists.boost.org/Archives/boost/2006/01/99522.php

I made specific proposal similar -but different-  to what you're doing here.
I failed to make a convincing case for it.  I let it rest because I knew
that sooner or later
the case for it would become more obvious.  I see that happening
now.  I confess that I thought the current process would last
at least one more release before breaking down so I was
wrong about that.

Robert Ramey




Beman Dawes wrote:

> The current approach to getting releases ready is completely broken in
> my opinion. Each release requires heroic efforts by the release
> manager, careful attention by many developers, and endless delays
> until
> everything is just right.
>
> This is discouraging to developers and, worse yet, important library
> upgrades and bug fixes are taking far too long to get into user's
> hands.
>
> The problems with the current release approach are not caused by
> release managers or developers, but rather by the release system
> itself. It just doesn't scale up to the number of libraries now in
> Boost, since every
> library has to be ready before a release can occur.
>
> These problems will only grow worse as more libraries are added.
>
> I propose changing to a different release model, one based on always
> maintaining a release-ready stable branch and merging updates for
> individual libraries into it asynchronously.
>
> A draft proposal is available at
> http://mysite.verizon.net/beman/release_overview.html.
>
> I've put a fair amount of thought into this proposal, and have run
> some Subversion simulations to make sure it works smoothly.
>
> What do others think?
>
> --Beman
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Anthony Williams-3]

Beman Dawes <bdawes@...> writes:

> A draft proposal is available at
> http://mysite.verizon.net/beman/release_overview.html.
>
> What do others think?

Looks good to me; I'm all for having a branch that's "release ready" at all
times. It is going to be tight getting all the regression tests run on all
platforms every week, though.

Anthony
--
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Thorsten Ottosen-3]

Beman Dawes wrote:

> A draft proposal is available at
> http://mysite.verizon.net/beman/release_overview.html.
>
> I've put a fair amount of thought into this proposal, and have run some
> Subversion simulations to make sure it works smoothly.

I like it for the most. A thing that is missing is how to
break the stable version when you do want to break it.

For example, often when libararies are redesigned, they give up
some compilers (Eg. spirit). Sometimes porting can really make a
developer feel worn-out.

As a concrete example, what happens when I commit the new version of the
range library. Can I simply mark some of the compilers as not supported
to get it into the stable-branch, or do I have to wait forever to get it
from trunk to stable?

Also, what happens if several libraries depend on your library in trunk,
but can't work with the dependency found in stable? But the version in
trunk is not ready to go to stable and so this will stall all libraries
that depend on that library?

-Thorsten

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Beman Dawes]

"Michael Fawcett" <michael.fawcett@...> wrote in message
news:bc5bffe80605110802m1bf6ca76k5056fb494148ce9e@......

> On 5/11/06, Beman Dawes <bdawes@...> wrote:
>
> <pasted from proposal>
>
>> We might say Sunday and Monday are merge days, Tuesday through Friday are
>> test days, > and Saturday is tag day. Since it is possible to
>> automatically tell if unexpected failures have > occurred, tagging can be
>> by automatically scheduled script.
>
> I know you were using a simplified example and you probably had
> something more concrete in mind, but do consider everyone's varying
> timezones (you probably did, or have a solution that makes the point
> moot).  Perhaps a SVN script that freezes stable during certain hours
> so that merges can't occur.  Then developers don't have to check some
> schedule online and do the time conversion themselves.

Good points. I've added a note on time slots.




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Beman Dawes]

"Simon Carter" <simon.carter@...> wrote in message
news:loom.20060511T171525-434@......

> Beman Dawes <bdawes <at> acm.org> writes:
>>
>> http://mysite.verizon.net/beman/release_overview.html.
>>
> The link is broken for me.
>
> I don't mind how the release is managed so long as I can use some kind of
> numbering system to completely identify the version of boost I have. As a
> minimum the overall boost version number should be incremented everytime
> anything in the release branch changes.
>
> I'm thinking of cases where I know my app worked with (say) boost 1_30_0
> but not
> with 1_32_0 - I need to be able to go back to the earlier version without
> jumping through hoops to reconstruct the state of the release branch at a
> particular point in time.

Good point. I've added a note to that effect, and suggested a number scheme
based on the current practice.

Thanks,

--Beman

PS: I'll update the proposal on the web as soon as I work through
outstanding comments.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Beman Dawes]

"Arkadiy Vertleyb" <vertleyb@...> wrote in message
news:e3vl3p$hd7$1@......

> "Beman Dawes" <bdawes@...> wrote
>
>> The problems with the current release approach are not caused by release
>> managers or developers, but rather by the release system itself. It just
>> doesn't scale up to the number of libraries now in Boost, since every
>> library has to be ready before a release can occur.
>>
>> These problems will only grow worse as more libraries are added.
>
> I think you are considering just one dimension of the problem.

Yes, and that is deliberate.See below.

> The other one -- the number of supported compilers is IMO equaly, if not
> even more, important.  The broken build can be detected only after the
> regressions run on all the compilers.  Which may be a few days (or a few
> weeks).  To fix the build would require a few more regression cycles, and
> by
> that time new errors can (and most likely will) be introduced.
>
> Something needs to be done about compiler availability -- this is the most
> critical issue, IMO.

Testing issues such as what compilers to support abd/or require are
certainly important.

Distribution issue (subsets, binaries, etc.) are also important.

If we try to fix all problems at once, I am afraid we will bog down in
details. IMO, the several dimensions of the general release problem are
separable. Hence the focus on fixing the release model as a separate task.

Thanks,

--Beman



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Ralf W. Grosse-Kunstleve]

--- Simon Carter <simon.carter@...> wrote:

> Beman Dawes <bdawes <at> acm.org> writes:
> >
> > http://mysite.verizon.net/beman/release_overview.html.

This proposal looks very good to me. I've not used boost releases for years. In
my experience boost developers are very motivated to fix incompatibilities if
they are discovered quickly. If things drag out the enthusiasm is significantly
reduced. Therefore I update and test locally at least once a week. It has been
working very well for us. The proposed mechanism seems similar. My experience
suggests a positive outcome. However, this will depend a lot on reasonably
quick availability of regression test results. I think running tests once a
week (on some platforms) is not enough.

> I don't mind how the release is managed so long as I can use some kind of
> numbering system to completely identify the version of boost I have. As a
> minimum the overall boost version number should be incremented everytime
> anything in the release branch changes.

SVN maintains a global revision number. Does anyone know a good way of making
this number available via a header file (e.g. boost/svn_revision_stable.hpp)?
I.e. each time any file in the stable branch changes the header file should
automatically be updated.

Cheers,
        Ralf


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Pedro Lamarão]

Thorsten Ottosen escreveu:

> As a concrete example, what happens when I commit the new version of the
> range library. Can I simply mark some of the compilers as not supported
> to get it into the stable-branch, or do I have to wait forever to get it
> from trunk to stable?

Your question is answered in the document:

"If and only if trunk changes for a library show no unexpected failures
on any required compiler/platform, the developer may merge those changes
into stable. If the merge causes any unexpected failures whatsoever, the
changes must be reverted immediately."

Later:

"An unexpected failure is any test that fails and is not marked up in
status/explicit-failures-markup.xml as an expected failure."

If a library don't support a compiler, then all tests can be "expected
failures", and the criteria for a marge is met.

> Also, what happens if several libraries depend on your library in trunk,
> but can't work with the dependency found in stable? But the version in
> trunk is not ready to go to stable and so this will stall all libraries
> that depend on that library?

This answer is also in the document, implied in the following paragraph:

"Problems with one library do not delay release of other libraries.
Although release of an update for a particular library may be delayed by
a dependency on another library, an upgrade for given library is never
delayed by a wait for a non-dependency library."

Yes, dependant libraries wait for dependencies to go in. This point
should be made more explicit, maybe in a separate "disadvantages" section.

This is a very _sound_ proposal.

--
Pedro Lamarão
Desenvolvimento

Intersix Technologies S.A.
SP: (55 11 3803-9300)
RJ: (55 21 3852-3240)
www.intersix.com.br

Your Security is our Business

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Sohail Somani]

> > Beman Dawes <bdawes <at> acm.org> writes:
> > >
> > > http://mysite.verizon.net/beman/release_overview.html.

This is awesome.

> SVN maintains a global revision number. Does anyone know a
> good way of making
> this number available via a header file (e.g.
> boost/svn_revision_stable.hpp)?
> I.e. each time any file in the stable branch changes the
> header file should
> automatically be updated.

You can run trigger scripts server side on checkins. I don't know if
sf.net allows this though (that is the boost repo right?)
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Rene Rivera]

Ralf W. Grosse-Kunstleve wrote:
> SVN maintains a global revision number. Does anyone know a good way of making
> this number available via a header file (e.g. boost/svn_revision_stable.hpp)?
> I.e. each time any file in the stable branch changes the header file should
> automatically be updated.

At minimum that should be possible with a commit script. It might not be
easy ;-)


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Stefan Seefeld]

Ralf W. Grosse-Kunstleve wrote:

> SVN maintains a global revision number. Does anyone know a good way of making
> this number available via a header file (e.g. boost/svn_revision_stable.hpp)?
> I.e. each time any file in the stable branch changes the header file should
> automatically be updated.

While this is probably possible, I don't think it is the right approach.
If you check out from the repository you do have that number, though not
as part of the sources (but somewhere in the .svn metadata.
For source packages that don't contain the .svn directories, the revision
number can easily be stored in a file during packaging.

Regards,
                Stefan
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Pedro Lamarão]

Ralf W. Grosse-Kunstleve escreveu:

> SVN maintains a global revision number. Does anyone know a good way of making
> this number available via a header file (e.g. boost/svn_revision_stable.hpp)?
> I.e. each time any file in the stable branch changes the header file should
> automatically be updated.

The keyword $Revision$ can substitute in a file the revision of the last
commit to that file. But that number won't change on commits to other files.

A tool is available, WCSubRev.exe, that reads the Subversion status of
all files in a working copy (excluding externals), and can substitute in
a file the revision of the last commit (among other things). It is
usually called in build scripts while making a (tag for) release.

--
Pedro Lamarão
Desenvolvimento

Intersix Technologies S.A.
SP: (55 11 3803-9300)
RJ: (55 21 3852-3240)
www.intersix.com.br

Your Security is our Business

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Beman Dawes]

Pedro Lamarão wrote:

> Beman Dawes escreveu:
>
>> I've put a fair amount of thought into this proposal, and have run some
>> Subversion simulations to make sure it works smoothly.
>>
>> What do others think?
>
> Here:
>
> "Formal releases occur on a regular schedule. The formal release
> procedure is simply to package up the last tagged revision of stable,
> publish release candidates, and decide if there are any issues serious
> enough to wait for the next stable tag point."
>
> If this process would contemplate a bugfix branches associated with
> stable tags, and if some backporting fixes effort were made, the people
> complaining about API stability would be happier.

Separate bug fix release were not envisioned. The known-stable point
releases serve as bug fix releases.

My intuitive feeling is that Boost library interfaces tend to stay
stable for relatively long periods of time, so API stability isn't an issue.

> No need to bugfix for ever; maybe just the previous release; or whatever
> is confortable enough. This should just give more longevity, and a
> healthier old age, to each Boost release.

The proposed model does not start with a fresh branch for each release.
Instead, the stable branch *becomes* the release branch. So there really
isn't such a thing as a bug fix branch that has to be maintained.

Thanks,

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Beman Dawes]

Robert Ramey wrote:

> This is on the right track.
>
>
> Not too long ago we had a discussion of this very topic
> a few months ago.
>
> see http://lists.boost.org/Archives/boost/2006/01/99522.php
>
> I made specific proposal similar -but different-  to what you're doing here.
> I failed to make a convincing case for it.  I let it rest because I knew
> that sooner or later
> the case for it would become more obvious.  I see that happening
> now.  I confess that I thought the current process would last
> at least one more release before breaking down so I was
> wrong about that.

I'd forgotten about that discussion, although I suspect your ideas were
a subconscious influence on my thinking. I've added an Acknowledgments
sections with a reference to your posting.

Thanks,

--Beman
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Beman Dawes]

Anthony Williams wrote:

> Beman Dawes <bdawes@...> writes:
>
>> A draft proposal is available at
>> http://mysite.verizon.net/beman/release_overview.html.
>>
>> What do others think?
>
> Looks good to me; I'm all for having a branch that's "release ready" at all
> times. It is going to be tight getting all the regression tests run on all
> platforms every week, though.

Yes, agreed. I first considered a longer cycle time, but then decided a
week was a much more natural unit.

Will there have to be some adjustments to some of the testing? Probably,
but I don't see that as a showstopper.

Thanks,

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost