Re: Proposal: Version Numbers and Tagging

Hi Warren,

I agree with this proposal. It make sens and it will be good for all of
us. But, I think that a mail is better to communicate version bumps,
since not everybody is always on IRC, and there are no logs of them.

We should add those rules should be added to the wiki, in a developer
section, as a reference.

That's a great addition to team cohesion!

Take care,

Francis Giraldeau

Warren Togami a écrit :
> 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
>   


-- 
Francis Giraldeau, Ing jr.
Analyste Infrastructure
Directeur Qualité
Téléphone : (819) 780-8955 poste 1111
Sans frais : 1-800-996-8955
Télécopieur : (819) 780-8871

Revolution Linux Inc.
2100 King ouest - bureau 260
Sherbrooke (Québec)
J1J 2E8 CANADA

http://www.revolutionlinux.com

Toutes les opinions et les prises de position exprimees dans ce courriel
sont celles de son auteur et ne representent pas necessairement celles
de Revolution Linux

Any views and opinions expressed in this email are solely those of the
author and do not necessarily represent those of Revolution Linux



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