[oi-dev] IPS repo organisation and versioning

[Ken Gunderson]

On Mon, 2011-05-30 at 23:25 +0100, Alasdair Lumsden wrote:
> Hi All,
> 
> After discussions online I wanted to flesh out proposals for the IPS repos and version numbers moving for the stable build and future dev builds.
> 
> Repo wise:
> 
> /release - for the stable releases
> /release-staging - a short-term staging area for us to test updates due to be published to /release, so we don't screw up peoples machines en-masse with untested updates
> 
> /dev - for our public consumption development releases, because we all know end users want bleeding edge desktop stuff.
> /dev-staging - a short-term place where /dev releases get tested, so that, again, we don't screw up peoples machines en-masse with untested stuff
> 
> /experimental - primarily for oi devs, where we put in-progress and known-broken updates for people collaborating on forthcoming features/releases. This would help for longer-term collaborative development of bigger changes.
> 
> This is an increase on the number of repos we have now, and I appreciate there's a maintenance cost, but when we launch stable we will definitely need to stage the updates. /dev-staging is just /dev-il renamed. /experimental is new and requested by a few people who want to work on things that will be unstable for a good few /dev releases.
> 
> Version wise:
> 
> The Oracle build numbers no longer make sense (eg 0.151 aka [snv|oi]_151), so with the forking we have an opportunity to switch to something saner. We've been talking about doing this for ages, but haven't really come up with something. I've had a proposal through from DeanoC which I've tweaked slightly, which I think makes sense for us to do in time for the stable release. I'd appreciate feedback.
> 
> For the first stable release, we could bump the version up to 1.0.0. The next stable release would be 2.0.0. Security and bug fixes would increment the last digit, so 1.0.X, eg 1.0.4.
> 
> /dev would increment the 1.X field, so you'd have eg 1.2, 1.3, etc. Respins of /dev (which will hopefully be less common) will bump the minor version, eg 1.3.1. When we are ready to release, this goes into /dev as 2.0.0, then /release when we're happy with it.
> 
> This lets people flip between /dev and /release on major versions, which I think is important. It also lets people at any point upgrade from /release to /dev without much hassle. It also means bug fixes and security updates into /release won't hold back people upgrading to /dev.
> 
> For the version numbers in /experimental, I'd suggest we use 1.X.X.X for this branch, so that the OI devs can switch between /dev and /experimental easily as the dev builds increase in number. I imagine /experimental at any one point will be based off /dev with a bunch of extra stuff added.
> 
> There is an alternative to the above, which is to ditch that component of the IPS version numbers, which has been mentioned. But I'm not sure how well that would work with flipping between repos and knowing what has been bug/security-fixed and what hasn't. The advantage of the version numbers above is that they're very clear.
> 
> Let me know if there are any reasons not to go with the above or any better alternatives.
> 
> Cheers,
> 
> Alasdair

I would give your specifics more thought but in general have found that
the *BSD models work well, i.e.:

RELEASE - this is stable release and the only stuff that gets updated
are security and other _critical_ patches, e.g. sanest thing to track
for production development.

STABLE - RELEASE plus MFC'd (merged from current) stuff that has been
well tested and scratches and common itch that would be too inconvenient
to wait for next RELEASE.

At first blush, this might appear analogous to your /dev proposal, but
not nearly so bleeding edge, i.e. could still run in production with
adequate testing.

CURRENT - the bleeding edge of development.

Code tends to flow from current to stable to release.  Other projects,
e.g. Debian, add another level in there but I think 3 is enough.  The
more branches the more dev time needed to maintain, and while 4 might
have some advantages I wonder if OI has the dev bandwidth to maintain 4
branches??