DragonFly versioning plan

Matthew Dillon dillon at apollo.backplane.com
Sun Sep 11 22:43:39 PDT 2011

    Hmm.  I still don't quite understand how the long-term release would
    work  Do we still do twice-a-year stable releases, but use the same
    pkgsrc as -current for them?  Or do we do away with the 6-month schedule

    We haven't been very good at MFCing stuff to stable.  There hasn't been
    a huge demand for it, either.  Most people use -current.  But at the same
    time the reason why most people use -current is because -current often
    winds up with all the new and cool stuff which -stable will never get.


    If I read this right, let me rephrase it and you tell me if I'm on
    the right track:  What we need to do is divorce the builds of the
    pkgsrc quarterlies from the dragonfly-release versioning.  That is, we
    would build and maintain a certain number of pkgsrc quarterlies but do
    it all for some designated release (up to 3 years old), and run THOSE
    packages not only on that designated release but also on all the releases
    inbetween AND ALSO ON -CURRENT.

    That is, we would not build the binary packages for -current on -current,
    we would build particular quarterlies but they would ALL be built on some
    specific prior release and they would be *run* on everything, including

    By building packages on a designated prior release but running on
    -current (as most of us do), any incompatibilities would become self
    evident and we would be able to fix them in -current to restore

    The only issue I see with this that might not be easily fixed would
    be compiler incompatibilities.

    Is that what you are saying?  Stick with our 6-month release but divorce
    all pkgsrc builds from DragonFly versioning entirely?


More information about the Kernel mailing list