Hello list,

the v14.8.11 that is upcoming this week after i have fixed one
more IMAP problem unveiled that the repository layout doesn't
scale.  Therefore it has been extended:

  [master]
    Only stable, but possibly backward-incompatible changes.
    History won't be rewritten.

  [release/*]
    E.g., [release/v14.8.10].
    Each release will henceforth create a new branch under
    release/, i.e., the role that [timeline] had (gained again).
    These branches will only consist of one commit, and that
    commit will be signed and used for the signed release tag.
    This is not true for most older releases, unfortunately. 

    I have created entries for all Mail/nail/Heirloom mailx and
    S-nail releases ever made.  (Though for Mail have i faked
    a v1.3.1 for 3BSD because that uses the same version number
    1.3 that is in 2BSD, however the code has changed.)
    History won't be rewritten.

  [release/latest]
    This is "a symbolic link" to the latest release branch.

  [release/stable]
    This is "a symbolic link" to the latest stable release branch.
    For now this is just the same as /latest, yet i will
    henceforth use this repo layout for all projects of mine and
    the support scripts will now this name.
    E.g., it is possible that v14.8.11 will remain /stable even if
    v14.9.0 is alreay released.

  [stable/*]
    E.g., [stable/v14.8].
    In here a new branch will be created for each new minor
    version, e.g., [stable/v14.7] "has been created once the
    v14.7.0 release was made, and extends to the v14.7.11
    release".

    I have created entries for any minor since v13.0.
    Unfortunately git(1) doesn't support symbolic links, so that
    there are no stable/latest and stable/stable entries.  Maybe
    i will add them when i have time to extend git hooks.
    History won't be rewritten.

  [next]   
    For daring users, pretty stable but new changes.
    History changes frequently.

  [crawl]
    Chaos, chaos, chaos.
    History changes permanently.

  [timeline]
    Whereas this leads back to Unix version 1, it has lost its
    meaning: it will gain the newest release also in the future,
    but _only_ if the version number is really higher than the
    last release.  E.g., if v14.8.12 would be released with
    v14.9.0 already being committed, it will not be joined in.
    Because: History won't be rewritten.

The README files and the web page haven't been updated yet.
Ciao.

--steffen

------------------------------------------------------------------------------
__________________________________
S-nail-users@lists.sourceforge.net

Reply via email to