You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@ebuilt.com> on 2001/01/25 14:38:37 UTC
release method for 2.0
I want to change the way we are numbering and producing releases.
We got onto a wrong track after the 0.8 releases and have been
constipated ever since. I want to go back to producing a version
every week or two (when the tree is not in mid-change) and decide
after the fact what quality to assign it:
snap -- just a CVS snapshot, may not compile
alpha -- packaged release that is believed to compile
but hasn't been tested under production conditions
beta -- packaged release that is known to compile on at
least three platforms and believed to be ready
for production use
current: public release of latest code
stable: public release of best code
What it requires is a change to the way we mark the version in the
source (something I was going to do anyway), a scripted release
process, and my time to do the RM stuff until we get it back to
a consisent process.
Are there any objections to me doing the above?
....Roy
Re: release method for 2.0
Posted by Tony Finch <do...@dotat.at>.
"Roy T. Fielding" <fi...@ebuilt.com> wrote:
>
>I want to go back to producing a version every week or two (when the
>tree is not in mid-change) and decide after the fact what quality to
>assign it:
Groovy, +1
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
"Perhaps on your way home you will pass someone in the dark,
and you will never know it, for they will be from outer space."
Re: release method for 2.0
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> No, by all means :-) I wouldn't change for the 1.3.17 stable tree,
> but this would be a great benefit for the 2.0 cycle. I'd like to
> see the exact schema before you commit it to the tree.
The only code change is moving version numbers out of httpd.h to
a smaller header file that it can include. Everything else is
just the social change of when (and why) a release is built.
I'd change 1.3.17 as well, but I'll leave that to others.
> Two big irks (for me) about what happens today...
>
> 1.3.17-dev sorts after 1.3.17, where the actual sequence of events
> it comes before. When I see a suffix, I presume it's an after-effect.
> Since 1.3.17-dev isn't 1.3.17, but 1.3.16-patched, it's confusing.
Yep. The change would be that, in cvs, it would always be "snap"
with the version number bumped every time we tagged the tree.
The progression would then be
2.0.17-current-snap ... tag ... 2.0.18-current-snap ...
|
V
2.0.17-current-alpha (initial build)
2.0.17-current-beta (when approved)
2.0.17-current-gold (when approved)
The point being that development would continue independent of the
release tarball status, and the only thing that would change in the
tarball is the define for release quality (snap, alpha, beta, gold).
Note that it would be changed outside of CVS, by the RM, according
to the vote on new-httpd.
> We also have no real schema to release a beta mid-cycle (that I've
> ever uncovered.) That is, we should progress from 1.3.16-stable
> to 1.3.16-patched to 1.3.beta-17 to 1.3.17. This flow midstream
> doesn't make much sense in our naming convention.
That's because we should never have allowed the last number to
be considered significant.
....Roy
Re: release method for 2.0
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Roy T. Fielding" <fi...@ebuilt.com>
Sent: Thursday, January 25, 2001 7:38 AM
> I want to change the way we are numbering and producing releases.
> We got onto a wrong track after the 0.8 releases and have been
> constipated ever since. I want to go back to producing a version
> every week or two (when the tree is not in mid-change) and decide
> after the fact what quality to assign it:
>
> snap -- just a CVS snapshot, may not compile
> alpha -- packaged release that is believed to compile
> but hasn't been tested under production conditions
> beta -- packaged release that is known to compile on at
> least three platforms and believed to be ready
> for production use
>
> current: public release of latest code
> stable: public release of best code
>
> What it requires is a change to the way we mark the version in the
> source (something I was going to do anyway), a scripted release
> process, and my time to do the RM stuff until we get it back to
> a consisent process.
>
> Are there any objections to me doing the above?
No, by all means :-) I wouldn't change for the 1.3.17 stable tree,
but this would be a great benefit for the 2.0 cycle. I'd like to
see the exact schema before you commit it to the tree.
Two big irks (for me) about what happens today...
1.3.17-dev sorts after 1.3.17, where the actual sequence of events
it comes before. When I see a suffix, I presume it's an after-effect.
Since 1.3.17-dev isn't 1.3.17, but 1.3.16-patched, it's confusing.
We also have no real schema to release a beta mid-cycle (that I've
ever uncovered.) That is, we should progress from 1.3.16-stable
to 1.3.16-patched to 1.3.beta-17 to 1.3.17. This flow midstream
doesn't make much sense in our naming convention.
If your suggestion addresses these issues, you have a convert :-)
Re: release method for 2.0
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> I'm probably not the best person to be RM right now, but I need
> to get back in the saddle again for some protocol development.
> And, quite frankly, the current release process has been one of
> the major reasons why I haven't been coding on Apache. So what
> I'd like to do is get the ball rolling, with the understanding that
> anyone is welcome to take the baton out of my hands as soon as
> they want to do so PROVIDED that they are going to move in the
> same direction and not back to constipation city.
+1
Bill
Re: release method for 2.0
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> I have a concern, but it isn't an objection, it is a concern. Roy, I
> trust your judgement, but you have not been very active in the code, and
> there have been multiple messages from you concerning how little time you
> have. I would much rather not have you as a limiting factor to get a
> release done, especially since you are not intimatelyt familiar with the
> code right now. I would rather see a detailed outline, and the work can
> then fall to anybody.
That was my biggest concern as well, and why I've been putting this
off for so long. But if we fix the immediate problem of futzing with
the release name within the code as part of the release process, then
the build can be as simple as
cvs tag new_version_tag
bump version number in repository for next release
./generate_httpd_release new_version_tag
The original role of RM wasn't as weighted on the build process
as it is now. There is no reason for anyone to be limited by the
actions of the RM if the tree is never frozen. The build itself
can be scripted. What the RM is supposed to do is collect the
unapplied patches from non-committers, commit those that need doing,
tag the tree, and inform people that something needs testing.
I'm probably not the best person to be RM right now, but I need
to get back in the saddle again for some protocol development.
And, quite frankly, the current release process has been one of
the major reasons why I haven't been coding on Apache. So what
I'd like to do is get the ball rolling, with the understanding that
anyone is welcome to take the baton out of my hands as soon as
they want to do so PROVIDED that they are going to move in the
same direction and not back to constipation city.
One unknown is how exactly to release apr and apr-util as part
of httpd, but I think we need to restart somewhere.
....Roy
Re: release method for 2.0
Posted by rb...@covalent.net.
> I want to change the way we are numbering and producing releases.
> We got onto a wrong track after the 0.8 releases and have been
> constipated ever since. I want to go back to producing a version
> every week or two (when the tree is not in mid-change) and decide
> after the fact what quality to assign it:
>
> snap -- just a CVS snapshot, may not compile
> alpha -- packaged release that is believed to compile
> but hasn't been tested under production conditions
> beta -- packaged release that is known to compile on at
> least three platforms and believed to be ready
> for production use
>
> current: public release of latest code
> stable: public release of best code
>
> What it requires is a change to the way we mark the version in the
> source (something I was going to do anyway), a scripted release
> process, and my time to do the RM stuff until we get it back to
> a consisent process.
>
> Are there any objections to me doing the above?
I have a concern, but it isn't an objection, it is a concern. Roy, I
trust your judgement, but you have not been very active in the code, and
there have been multiple messages from you concerning how little time you
have. I would much rather not have you as a limiting factor to get a
release done, especially since you are not intimatelyt familiar with the
code right now. I would rather see a detailed outline, and the work can
then fall to anybody.
Just some thoughts.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------