todo for 1.2.0-pre
haski at sezampro.yu
Mon Nov 10 20:01:51 PST 2003
On Mon, Nov 10, 2003 at 08:23:21PM -0700, Kevin P. Fleming wrote:
> >So basically, we'll simply use branches only for pre releases:
> >tag: v1_2_0_rc1 v1_2_0_rc2 v1_2_0
> > +--+--------------+--------------+
> > | \ \
> > --+--+------+---+--------+-----+-----+--+---+--+-->
> >tag: v1_2_0_rc
> >branch: v1_2_0_rc_branch
> This is very similar to what I had been thinking, which was:
> - branch as "1_2_0", then update bootstrap.configure with "1.2.0-rc1" as
> the version number and commit to the branch, then tag as 1_2_0_rc1 (so
> the version number change is included in the tagged files)
Yes, that's what that little +--+ on the branch should represent. :)
And I agree that vX_Y_Z_branch for a branch name would be better
(instead of vX_Y_Z_rc_branch), as X.Y.Z release is going to happen
there after all.
> In this scenario, the 1_2_0 branch would never be merged back into
> rather any patches applied to the 1_2_0 branch that were applicable to
> HEAD would be committed there separately. I can't say whether that's
> better or worse, just different :-) However, as soon as HEAD is
> available for 1.2.1 development, I want to update all the handlers to
> support syntax version 3.2 and start that development, and that could
> make merging from 1_2_0 back to HEAD a complicated process.
We should merge the changes if possible, if not, just apply them
manually as you say. But that's not a big deal. Nor the changes
between pre releases should be that big (hopefully).
> >Packaging a release. Kevin's script that creates CVS snapshots seems
> >to be doing a good job, so I guess this is already done? Is changing
> >the version in bootstrap.configure the only thing necessary to create
> >the package with the right name, included documentation that will be
> >installed in the right place, etc. ?
> It seems to be working well, yes. The version number embedded in
> bootstrap.configure flows into the code as a PACKAGE_VERSION define, and
> the code has been modified to use that, so there shouldn't be any other
> places to change the version number. I haven't heard from anyone that
> has tested the snapshots to make sure they install properly on their
> system (especially since the docs have been integrated) but they work
> for me, for whatever that's worth.
I'd complain if they didn't work for me (I tried them of course). :)
> >nALFS homepage. This is the last thing that makes nALFS kinda
> >dependent on me and I would like to allow others to mess with it too
> >(so I can finally send you all to hell and go do something else ;).
> There is also text in README that needs updating to reference the LFS
> website as the "official" home of nALFS.
Much of the text in README can be removed too, once the information is
transferred to User's guide.
More information about the alfs-discuss