DragonFly versioning plan

[Justin Sherrill]

(Whoops, forgot to reply all.)

I have the pkgsrc and DragonFly release stuff both in there because
they affect each other.  I don't have a problem with 6 month release
cycles, but there's nothing supporting a need for it. - we've had a
number of releases where we delayed well past it.

Tracking what's stable at time of release is what I do now.  Which
works for the release versions, but perhaps not for non-release.  I've
always been worried about breakage with that.  I'd rather have two
DragonFly categories: One where the long term support where there's
always packages and any system updates are minor, to guarantee a
stable platform.  The other, where there's clear expectations the user
will update the system and pkgsrc on a semi-regular basis.  This is, I
think, sort of like Debian 'stable' and 'unstable', in a broad way.

The goal here is to have release strategy match the usage patterns
I've observed in general.

On Sun, Sep 11, 2011 at 12:11 AM, Chris Turner
<c.turner at 199technologies.com> wrote:
> On 09/10/11 20:28, Justin Sherrill wrote:
>>
>> Here's the problems I'm trying to fix:
>
> think it makes sense to separate the pkgsrc-tracking issues from
> the system-release issues as much as possible - these seem a bit
> bound up together in the proposal from what I can see
>
>> - I've been building pkgsrc quarterly releases for binaries, which is
>> fine, but it would also be nice to have pkgsrc-current reports to show
>> how much breakage there would be.
>
> for really-long-term-release:
>
> seems like the need for this was bound up with pkgsrc building troubles -
> not sure why the ~6/mo cycle is a problem in-and-of-itself otherwise
>
> unless I am mistaken?
>
> yeah - I think the 'preview' stuff is pretty much unused though..
>
> also - too much drift/delta between head and branches makes both bug MFC's
> and pkg assuptions break, etc..
>
> for the pkgsrc-branching-vs-df-release:
>
> why not just 'only track whatever is latest stable pkgsrc at time of
> release' ?
>
> this prevents the problems of needing 2x stable pkgsrc builds for a given
> release -
> if people want new packages ... see 'for head-builds' below
>
> for head-builds:
>
> build 'latest current pkgsrc' and 'latest stable pkgsrc'
>
> this isolates pkgsrc instability from git-tip DF users, but
> still allows testing / showing 'what will break' in pkgsrc-head
>
> having accidentally tried pkgsrc-head a few times I don't like the idea
> of imposing either 'whatever is in pkgsrc head' or '2y old release' on
> new/binary users.. personally I'll keep building my packages from stable
> though..
>
> I don't think we care so much about paying attention / testing
> pkgsrc-current
> vs latest-stable-release breakage - unless I'm mistaken.
>
> the biggest issue imho is getting fixes upstream into pkgsrc and how that
> ties into the pkgsrc relases - but I don't have to maintain the build setup
> :D
> and I haven't tried too hard - simply maintained my own '/usr/pkgsrc/local'
> grab bag
> which has long been on my todo list to get merged (aah life circumstances) -
> having
> some kind of 'coordination effort' about this I think would help here but
> maybe
> that's me being lazy and not getting involved with the pkgsrc people.. hmm
>
> also - maybe moving / standardizing the pkg-build scripting in-tree would
> ease
> administration of the builds? e.g. where it's pretty straightforward to
> reproduce
> the 'official build' setup, etc more people can contribute / test /
> reproduce, etc.
>
> I am admittedly not as involved with things these days as I'd like to be
> so .. not sure of all the issues that relate w/r/t build setup .. but..
> some 2c I suppose
>
> cheers,
>
> - Chris
>