httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: just say no (was: Re: Release Strategy)
Date Mon, 05 Feb 2001 21:12:19 GMT

> Okay... you don't need to do a checkout with two tags. Yes, that would be
> painful.
> $ cvs checkout http-2.0
> [ build. prelim test. seems reasonable. ]
> $ cvs tag APACHE_2_0_11
> [ tags based on what is in the *working* directory; while the person did the
>   build and prelim test, other people were checking stuff in. that doesn't
>   get tagged. ]
> $ tar czf the-tarball
> --- several days later ---
> [ assuming a new working directory; this first isn't needed if the working
>   dir was kept from before ]
> $ cvs checkout -rAPACHE_2_0_11 httpd-2.0
> $ edit include/ap_release.h
> $ cvs commit include/ap_release.h
> $ cvs tag APACHE_2_0_11_beta
> The second tag just goes over the whole tree. No need to restrict it to
> ap_release.h.

This is exactly what I said in my very first mail about this.  You said
you didn't want a second tag.

> > My understanding of how other people want to do this (and it is VERY
> > possible that I am mis-understanding), is that we tag and roll once a
> > week.
> Whenever the RM feels like it, actually. We know the last tarball is dead,
> so we can wait for the OS/2 fixes and roll a new one right after that
> commit. No schedules are needed.  Read: flexibility :-)

Yeah, but we are likely to do this once a week, if for no other reason
than because it is easier to just put it in crontab.  We can always do
more, but once a week is a good regular time, that allows people to shoot
for a given target.y

> > The whole time, HEAD is continuing to develop, so big changes are still
> > going in, which means the next release may or may not be as good or better
> > than the current tarball.
> Yup!
> Now. Let's say the tarball is broken, with just a couple minor things. We
> don't patch it. We just throw it out and wait for the next tarball to be
> built. If big changes were occurring, then it might be a bit longer.
> We don't want to start maintaining branches (or worse: separate trees). If
> somebody doesn't work, we punt and try again later.
> We are all motivated to get a release out, so I don't think there will be
> gratuitous changes if we all know we're "close". But we also don't want to
> return to a "heavy" process that would involved branches or trees.
> "Doesn't work? Oh well. Maybe the next one will."

My concern, is that with this strategy, we will NEVER see a real
release.  I understand the idea, what I don't see is how this moves us
towards a beta or a GA release.  If you can explain that to me, I am
likely to agree.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message