todo for 1.2.0-pre

Kevin P. Fleming kpfleming at
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
> go.


> 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 mailing list