todo for 1.2.0-pre
Kevin P. Fleming
kpfleming at linuxfromscratch.org
Mon Nov 10 19:23:21 PST 2003
Neven Has wrote:
(somewhat long reply, but these are complicated subjects)
> I'm thinking about tagging the current code (v1_2_0_rc) and
> immediately create a branch (v1_2_0_rc_branch), without worrying too
> much whether this will be the exact code for 1.2.0-pre1 or not (it
> won't). It's just a moment when we're close to release the first pre
> version (as the tag name suggests).
I've been thinking along similar lines, except tagging _after_ branching
instead of before.
> On the branch, we can then make necessary changes for pre1, and start
> releasing those pre versions (tagging them along the way --
> v1_2_0_rc1, v1_2_0_rc2...). On the main trunk, we can continue the
> development for the next version (1.2.1), merging pre changes as we
> 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)
- additional changes to the 1_2 branch would get committed, at some
point bootstrap.configure would be updated to "1.2.0-rc2" and committed,
then tagged as 1_2_0_rc2
- when ready, bootstrap.configure would get updated to "1.2.0" and
committed, tagged as 1_2_0 and it's done
In this scenario, the 1_2_0 branch would never be merged back into HEAD,
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.
> 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.
> 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.
> This should be probably sent to webpage mailing list, I can repost it
> there if necessary. For now, maybe we can simply put all
> ~neven/nALFS/ stuff under download/nALFS ? Until we find the better
> location. Or something like that...?
That would work, yes. I've only quickly looked over the contents of
/~neven, but it looks like most of the text has already been
incorporated into the main ALFS site, so it's mostly the links and any
additional text copying.
More information about the alfs-discuss