Proposal: Version Numbers and Tagging

dberkholz, vagrantc and I have agreed on the following methodology for
tagging version numbers in the ltsp usptream source repositories.  This
transitional procedure to get LTSP upstream used to tagging and version
numbers.  At some point later we will come to agreement on making things
we call releases.

We would begin this methodology late Wednesday after we convert the
repository to pack-92 as proposed in the previous message.

Proposal: Version Numbers and Tagging
=====================================

First we begin with these version numbers.

ltsp-5.1.1
ldm-2.0.0
ltspfs-0.5.0

The rightmost number is incremented and tagged whenever any distro feels
like doing so, usually when they build it into their distro.
Incrementing and tagging a version number could theoretically happen at
any arbitrary time, but distro maintainers should exercise courtesy
toward others by COMMUNICATING on IRC their intentions before doing it.
    If a tag happens and somebody else wanted to add something, no big
deal, just push and tag again.  If a previous maintainer broke something
for another distro they should be scolded harshly, then it should be
fixed in the repo and tagged when desired.

Why this seemingly odd arrangement for version numbers?
=======================================================

1) This ensures autonomy of distro maintainers, so distro maintainers
need not wait for agreement from others to build in their own distro
directly from upstream.
2) This encourages more upstreaming of previously distro-specific branch
  code due to this low bar of upstream versioning.
3) This makes it easier to communicate when things were added or fixed.
  "FOO was added in 5.1.27.  5.1.30 is in Gentoo.  Fedora has 5.1.25 so
they need to upgrade."

Version Inflation Mitigating Factors
====================================

* Distro maintainers exercise courtesy toward others by communicating
intention to tag in IRC before doing it.  Through natural cooperation
this might often have the same version number be used by multiple distros.
* In many cases distros might do builds without upstream checkins.  For
example, Fedora RPMS often increment the Release number when adding
revisions in package builds.  When a few revisions are well tested they
are pushed pushed back upstream.
* Distro maintainers are discouraged from doing it too often.  They have
the FLEXIBILITY to do so but it is considered poor form if they checked
in bad code, tagged, only to do it again an hour later because they
didn't test it.

Official Releases
=================
At some point later after we have a number of distributions integrated
nicely and our common components are in better shape, we might realize,
"Wow, this is looking pretty good and nothing changed in 4 days.  Time
to release?"

Then we exercise some plan that involves disallowing new features, ask
for translations, do more testing, then release 5.2.0.  The exact
details of a plan we would figure out later.

LDM
===
ldm-2.0.x will be used for a while.
ldm-2.1.x will happen if a protocol change happens.  ldm-2.0 should be
branched upstream if any distro wants to continue maintenance of the old
version.

Similar branches may happen for older versions of ltsp or ltspfs if
maintenance of an older version is desired by any distro.

Any objections?

Warren Togami
[email protected]


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net