[MidoNet] [MidoNet-dev] MidoNet release cycle

Jean-François Joly jf at midokura.com
Tue Jun 30 09:55:14 UTC 2015


Hi Sandro,

First, I wouldn't block anything with the discussion. Let's release as soon
as possible.

+1 to this version numbering move, I saw the change in Openstack and was
going to suggest the same.

I'm in favor of following the semantic versioning [1]: we would release the
first version as 4.0.0 (if we change for 2015.06) or 5.0.0 ( 2015.09).
Subsequent releases would have X (major) updated only if the APIs are
incompatible.

Semantic versioning in short:

   1. MAJOR version when you make incompatible API changes,
   2. MINOR version when you add functionality in a backwards-compatible
   manner, and
   3. PATCH version when you make backwards-compatible bug fixes.


Thanks,

JF



[1] http://semver.org/


On Tue, Jun 30, 2015 at 10:50 AM, Sandro Mathys <sandro at midokura.com> wrote:

> Thanks JF, very good overview and explanation :)
>
> However, I'd like to re-open the discussion in one point: release
> versioning. So far we're following a YYYY.MM schema, but truth is -
> not a single release so far happened in the month it was scheduled for
> and I doubt 2015.06 will make it [0]. We also said the release version
> would be changed if there's a delay, i.e. what was originally planned
> to be released as 2015.06 would now be released as 2015.07. While I
> think that's the correct way to do it, it can also lead to confusion
> as references to the original version might still exist (in the wiki,
> logs, people's minds, ...). To be honest, there's not many projects
> out there that use YYYY.MM simply because it's very hard to release on
> time and requires a lot of resources (and a strong will to postpone
> features that don't make it) - and we don't exactly have too much
> resources, do we?
>
> Therefore, I suggest we do it like OpenStack does (post-kilo) [1] and
> switch to a X.Y.Z or similar version schema. Maybe X.Y is good enough
> though. So the versions would change as follows:
> 2015.06 -> 4.0.0
> 2015.09 -> 5.0.0
> 2015.12 -> 6.0.0
> 2016.03 -> 7.0.0
>
> So with X in X.Y.Z defined, that leaves us to defining Y and Z. Y
> could be bugfix releases and Z security releases if that makes sense.
> Or we could use Y for both and not use Z, i.e. go with only just X.Y.
>
> Thoughts?
>
> Cheers,
> Sandro
>
> [0] http://wiki.midonet.org/Release%20Schedule
> [1] http://ttx.re/new-versioning.html
>
> On Mon, Jun 29, 2015 at 7:56 PM, Jean-François Joly <jf at midokura.com>
> wrote:
> > Hi everyone,
> >
> > I started to document the updated release cycle[1] based on the
> discussions
> > on this mailing list.
> >
> > The highlights are:
> > - Release every 3 month (one release is focused on feature, the next one
> on
> > stability)
> > - The stable release is scheduled between one month and 2 weeks before
> the
> > release of Openstack
> > - The releases will be maintained: i.e. they get bug fixes during 6
> months
> > (N+1)
> >
> > The first release to receive bug fixes will be 2015.06.
> >
> > Thanks,
> > JF
> >
> > [1]: http://wiki.midonet.org/Release%20Cycle
> >
> > On Tue, Jun 2, 2015 at 8:12 AM, Sandro Mathys <sandro at midokura.com>
> wrote:
> >>
> >> On Tue, May 26, 2015 at 9:00 AM, Antoni Segura Puimedon
> >> <toni+midonet at midokura.com> wrote:
> >> > Sandro,
> >> >
> >> > Now that there's been so enough votes, could you draft it up for the
> >> > wiki/community page?
> >>
> >> Yes, will do. But working out some details yet.
> >>
> >> >>> On Mon, 25 May 2015 09:46, Jean-François Joly wrote:
> >> >>> > 5/ Release dates
> >> >>> > If I read correctly the timeline from Toni's proposal, we are
> >> >>> > releasing before Openstack, this is a good point to clarify, do we
> >> >>> > release just before or just after the Openstack releases?
> Releasing
> >> >>> > just before has the great advantage to allow the distribution to
> >> >>> > integrate the latest version of MidoNet when they package the new
> >> >>> > Openstack release.
> >> >>> > On the other hand, ensuring the plugin compatibility before the
> >> >>> > release might be challenging as last minute fixes during the
> testing
> >> >>> > of the Openstack releases might break the integration.
> >> >>> > I also agreed with Sandro and Toni that the number should
> correspond
> >> >>> > to the month of the release.
> >>
> >> Well, OpenStack's code freeze is more than one month before their
> >> release date, so there should be no unexpected major changes anymore.
> >> In the hopefully extremely rare case where they have to make a change
> >> that breaks our compatibility, we should probably do a bugfix /
> >> backport release - I doubt this is likely to happen and even if it
> >> does, would probably only require minor low-effort changes on our
> >> side.
> >>
> >> That said, releasing a full month ahead might be a bit early.
> >> Shouldn't two weeks be enough? Not sure what work is necessary between
> >> a MidoNet release and an OpenStack release - can someone clarify? For
> >> the distributions, it should still be good enough if we released the
> >> same day as OpenStack (with alpha/beta releases or release candidates
> >> beforehand).
> >>
> >> >>> > On Mon, May 25, 2015 at 7:53 AM, Samir Ibradžić <
> samir at midokura.com>
> >> >>> > wrote:
> >> >>> > > We can sync *full stable* releases with OSt, yet I like the
> Galo's
> >> >>> > > proposition better, 3-months releases, to keep up the pace. For
> >> >>> > > OSt
> >> >>> > > synced
> >> >>> > > releases we can focus on stability & robustness, and on those
> >> >>> > > mid-term
> >> >>> > > releases we can focus on adding features. Something similar to
> old
> >> >>> > > Linux
> >> >>> > > kernel version-ing scheme, with odd & even numbers designating
> >> >>> > > stability.
> >>
> >> Indeed, that would work and sounds like a good proposal. Let's do it so
> :)
> >>
> >> So, if I understand correctly, we would have an alternating release
> >> model as follows:
> >> - 4 months before an OpenStack release, we release a major new version
> >> with lots of new features
> >> - 1 month before an OpenStack release, we release a minor new version
> >> with hardly any new features but very stabilized and better
> >> compatibility to the upcoming OpenStack/Neutron release
> >>
> >> (Or 3.5 and 0.5 months, as suggested above).
> >>
> >> How do we intend to deal with this on the development and release
> >> management side? (Most) new features obviously can't go into a minor
> >> release, so should trunk/master only be used for major releases and
> >> minor releases be worked on in branches? If so, how do minor releases
> >> differ from backport releases? What are backport releases in this new
> >> model, anyway?
> >>
> >> Cheers,
> >> Sandro
> >>
> >> >>> > > On 2015年05月25日 10:57, Ryu Ishimoto wrote:
> >> >>> > >>
> >> >>> > >>
> >> >>> > >> +1 on aligning with the OSt release sched but start off with a
> >> >>> > >> short
> >> >>> > >> backport period (X + 1, for example) with flexibility to
> revisit
> >> >>> > >> and
> >> >>> > >> extend later based on resource availability and demands
> >> >>> > >>
> >> >>> > >> Ryu
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >> On Mon, May 25, 2015 at 4:01 AM, Irena Berezovsky
> >> >>> > >> <irenab.dev at gmail.com
> >> >>> > >> <mailto:irenab.dev at gmail.com>> wrote:
> >> >>> > >>
> >> >>> > >>     +1.
> >> >>> > >>     Following the recent openstack big tent model
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> http://www.eweek.com/cloud/openstack-moves-from-integrated-release-to-big-tent-model.html
> >> >>> > >>     adoption of  the openstack release policy will allow us to
> be
> >> >>> > >> one of
> >> >>> > >>     the "blessed: openstack project.
> >> >>> > >>
> >> >>> > >>     BR,
> >> >>> > >>     Irena
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>     On Fri, May 22, 2015 at 9:33 AM, Sandro Mathys
> >> >>> > >> <sandro at midokura.com
> >> >>> > >>     <mailto:sandro at midokura.com>> wrote:
> >> >>> > >>
> >> >>> > >>         JF, thanks for bringing this up. Like Toni, I'm glad
> this
> >> >>> > >> has
> >> >>> > >>         been brought up, it's also been on my mind for a while.
> >> >>> > >>
> >> >>> > >>         +1 to Toni / Tomoe. Let me elaborate my own reasoning
> >> >>> > >> behind
> >> >>> > >>         this a bit.
> >> >>> > >>
> >> >>> > >>         Syncing with OpenStack releases would indeed make it
> much
> >> >>> > >> easier
> >> >>> > >>         for integrators. OpenStack distributions can package
> and
> >> >>> > >> ship it
> >> >>> > >>         together with the new OpenStack release that way. But
> >> >>> > >> also
> >> >>> > >> Linux
> >> >>> > >>         distributions like Ubuntu and Fedora are in sync with
> the
> >> >>> > >>         OpenStack release cycle, so it's easier for them as
> well
> >> >>> > >> (and
> >> >>> > >>         they both are likely to package it together with their
> >> >>> > >> OpenStack
> >> >>> > >>         distributions anyway). However, we shouldn't ignore
> other
> >> >>> > >> use
> >> >>> > >>         cases - even though most of our users are likely to use
> >> >>> > >> MidoNet
> >> >>> > >>         with OpenStack, there might be others as well.
> >> >>> > >> Nevertheless,
> >> >>> > >>         syncing with OpenStack should not harm any of these use
> >> >>> > >> cases
> >> >>> > >>         (significantly) and there's no conflicting schedule
> that
> >> >>> > >> I'm
> >> >>> > >>         aware of.
> >> >>> > >>
> >> >>> > >>         Waiting 6 months for new features is not a long time at
> >> >>> > >> all
> >> >>> > >> -
> >> >>> > >>         you don't upgrade your SDN immediately anyway, do you?
> -
> >> >>> > >> but
> >> >>> > >>         enables us to implement more and bigger features, while
> >> >>> > >> reducing
> >> >>> > >>         the risk of delayed releases. It also allows for a
> >> >>> > >> extended
> >> >>> > >>         testing period. Users who can't wait, can use nightlies
> >> >>> > >> or
> >> >>> > >>         release candidates if they really think they must. I'm
> a
> >> >>> > >> fan
> >> >>> > >> of
> >> >>> > >>         the "release early, release often" philosophy, but
> >> >>> > >> everything
> >> >>> > >>         has it's limits where it just doesn't make much sense
> >> >>> > >> anymore
> >> >>> > >>         and a release every two or three months is just too
> much.
> >> >>> > >>
> >> >>> > >>         Regarding the backport period, I would rather see
> "(X+2)"
> >> >>> > >> like
> >> >>> > >>         OpenStack, but "(X+1) + 3 months" is a very good start
> >> >>> > >> and I
> >> >>> > >>         could even live with only "(X+1)" as our resources are
> >> >>> > >> currently
> >> >>> > >>         very limited. However, we might want to revisit this,
> >> >>> > >> once
> >> >>> > >> we
> >> >>> > >>         have more helping hands.
> >> >>> > >>
> >> >>> > >>         Oh, and I believe e.g. "2015.03" referred to the month
> >> >>> > >> the
> >> >>> > >>         branching was done in, right? With this change - and I
> >> >>> > >> think
> >> >>> > >>         that's also true for the months given in Toni's
> proposal
> >> >>> > >> -
> >> >>> > >> it
> >> >>> > >>         should refer to the (scheduled) release month instead.
> >> >>> > >>
> >> >>> > >>         Cheers,
> >> >>> > >>         Sandro
> >> >>> > >>
> >> >>> > >>         On Fri, May 22, 2015 at 9:30 AM, Tomoe Sugihara
> >> >>> > >>         <tomoe at midokura.com <mailto:tomoe at midokura.com>>
> wrote:
> >> >>> > >>
> >> >>> > >>             +1 to Toni for going with 6 month cycle to be
> >> >>> > >> friendly
> >> >>> > >> with
> >> >>> > >>             OpenStack as this would simplify things for both
> >> >>> > >> users
> >> >>> > >> and
> >> >>> > >> devs.
> >> >>> > >>               I hope producing nightlies (as we do now) and/or
> do
> >> >>> > >> some
> >> >>> > >>             milestone releases like OpenStack would help eager
> >> >>> > >> users
> >> >>> > >> to
> >> >>> > >>             try out new features before an official release.
> >> >>> > >>
> >> >>> > >>             Regarding the backporting period, "until release
> date
> >> >>> > >> of
> >> >>> > >>             (X+1) + 3 months" sounds like a good start. But,
> I'd
> >> >>> > >> like to
> >> >>> > >>             know what users would need.
> >> >>> > >>
> >> >>> > >>             Tomoe
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>             On Thu, May 21, 2015 at 2:03 PM, Antoni Segura
> >> >>> > >> Puimedon
> >> >>> > >>             <toni+midonet at midokura.com
> >> >>> > >>             <mailto:toni+midonet at midokura.com>> wrote:
> >> >>> > >>
> >> >>> > >>                 Sorry about the render size, re-attaching:
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>                 On Thu, May 21, 2015 at 2:01 PM, Antoni Segura
> >> >>> > >> Puimedon
> >> >>> > >>                 <toni+midonet at midokura.com
> >> >>> > >>                 <mailto:toni+midonet at midokura.com>> wrote:
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>                     On Thu, May 21, 2015 at 8:52 AM,
> >> >>> > >> Jean-François
> >> >>> > >> Joly
> >> >>> > >>                     <jf at midokura.com <mailto:jf at midokura.com>>
> >> >>> > >> wrote:
> >> >>> > >>
> >> >>> > >>                         [updated the diagram to correct a typo]
> >> >>> > >>
> >> >>> > >>                         Hi everyone,
> >> >>> > >>
> >> >>> > >>                         We currently release MidoNet every two
> >> >>> > >> months:
> >> >>> > >>                         2014.11 , 2015.01 , 2015.03 and soon
> >> >>> > >> 2015.05.
> >> >>> > >>                         The current schedule is detailed in
> wiki
> >> >>> > >>
> >> >>> > >> <http://wiki.midonet.org/Release%20Schedule>.
> >> >>> > >>
> >> >>> > >>                         This has many advantages:
> >> >>> > >>
> >> >>> > >>                           * simple and predictable schedule
> >> >>> > >>                           * new features frequently released
> >> >>> > >>
> >> >>> > >>                         On the other hand, it presents several
> >> >>> > >> challenges:
> >> >>> > >>
> >> >>> > >>                           * frequent upgrades
> >> >>> > >>                           * new features can introduce new bugs
> >> >>> > >>                           * bug fixes aren't available until
> the
> >> >>> > >> next
> >> >>> > >>                             release
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>                         I'm suggesting to change our release
> >> >>> > >> schedule as
> >> >>> > >>                         follows:
> >> >>> > >>
> >> >>> > >>                           * quarterly releases (approximately
> >> >>> > >> every
> >> >>> > >> 3
> >> >>> > >>                             months)
> >> >>> > >>                           * ad-hoc patch releases during 6
> months
> >> >>> > >>                             (example: 2015.05.1 for the first
> >> >>> > >> patch
> >> >>> > >>                             release of 2015.05)
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>                     I'm very glad this is brought up. From the
> >> >>> > >> OpenStack
> >> >>> > >>                     integration perspective though, I think it
> >> >>> > >> would
> >> >>> > >> be
> >> >>> > >>                     much more convenience to go with a 6 month
> >> >>> > >> cycle.
> >> >>> > >>                     This way, our next releases would be
> >> >>> > >>                     2015.09 and then 2016.03.
> >> >>> > >>
> >> >>> > >>                     That would allow us to release with enough
> >> >>> > >> margin to
> >> >>> > >>                     integrate well with the following OSt
> release
> >> >>> > >> (they
> >> >>> > >>                     do .04 and .10) and the longer cycle would
> >> >>> > >> help
> >> >>> > >> even
> >> >>> > >>                     more with the upgrading nuisance of the
> >> >>> > >> upstream
> >> >>> > >>                     version. Of course, it is a trade-off of
> >> >>> > >> feature
> >> >>> > >>                     availability vs release shelf life.
> >> >>> > >>
> >> >>> > >>                     I'd be looking at having each release X to
> >> >>> > >> have
> >> >>> > >>                     security and regression fixes until release
> >> >>> > >> date
> >> >>> > >> of
> >> >>> > >>                     (X+1) + 3 months. For instance.
> >> >>> > >>                     The life of the 2015.9 release would live
> >> >>> > >> until
> >> >>> > >> 2016.6.
> >> >>> > >>
> >> >>> > >>                     Find attached a picture of how it would
> look
> >> >>> > >> like.
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>                         Enclosed is a diagram of the
> >> >>> > >> corresponding
> >> >>> > >>                         release cycle.
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>                         We would hold a monthly release meeting
> >> >>> > >> to
> >> >>> > >> share
> >> >>> > >>                         the status of the upcoming release and
> >> >>> > >> decide if
> >> >>> > >>                         a patch release is necessary.
> >> >>> > >>
> >> >>> > >>                         Please share your feedback;
> >> >>> > >>                         I have added this as an agenda item for
> >> >>> > >> our
> >> >>> > >> next
> >> >>> > >>                         council meeting
> >> >>> > >>
> >> >>> > >> <http://wiki.midonet.org/CommunityCouncil/Meetings/2015-05-26
> >.
> >> >>> > >>
> >> >>> > >>                         Thanks,
> >> >>> > >>                         JF
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >> _______________________________________________
> >> >>> > >>                         MidoNet-dev mailing list
> >> >>> > >>                         MidoNet-dev at lists.midonet.org
> >> >>> > >>                         <mailto:MidoNet-dev at lists.midonet.org>
> >> >>> > >>
> >> >>> > >> http://lists.midonet.org/listinfo/midonet-dev
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>                 _______________________________________________
> >> >>> > >>                 MidoNet mailing list
> >> >>> > >>                 MidoNet at lists.midonet.org
> >> >>> > >> <mailto:MidoNet at lists.midonet.org>
> >> >>> > >>                 http://lists.midonet.org/listinfo/midonet
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>             _______________________________________________
> >> >>> > >>             MidoNet-dev mailing list
> >> >>> > >>             MidoNet-dev at lists.midonet.org
> >> >>> > >>             <mailto:MidoNet-dev at lists.midonet.org>
> >> >>> > >>             http://lists.midonet.org/listinfo/midonet-dev
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>         _______________________________________________
> >> >>> > >>         MidoNet-dev mailing list
> >> >>> > >>         MidoNet-dev at lists.midonet.org
> >> >>> > >> <mailto:MidoNet-dev at lists.midonet.org>
> >> >>> > >>         http://lists.midonet.org/listinfo/midonet-dev
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>     _______________________________________________
> >> >>> > >>     MidoNet-dev mailing list
> >> >>> > >>     MidoNet-dev at lists.midonet.org
> >> >>> > >> <mailto:MidoNet-dev at lists.midonet.org>
> >> >>> > >>     http://lists.midonet.org/listinfo/midonet-dev
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >>
> >> >>> > >> _______________________________________________
> >> >>> > >> MidoNet mailing list
> >> >>> > >> MidoNet at lists.midonet.org
> >> >>> > >> http://lists.midonet.org/listinfo/midonet
> >> >>> > >>
> >> >>> > > _______________________________________________
> >> >>> > > MidoNet mailing list
> >> >>> > > MidoNet at lists.midonet.org
> >> >>> > > http://lists.midonet.org/listinfo/midonet
> >> >>> > _______________________________________________
> >> >>> > MidoNet mailing list
> >> >>> > MidoNet at lists.midonet.org
> >> >>> > http://lists.midonet.org/listinfo/midonet
> >> >>>
> >> >>> --
> >> >>> Jaume Devesa
> >> >>> Software Engineer at Midokura
> >> >>> _______________________________________________
> >> >>> MidoNet mailing list
> >> >>> MidoNet at lists.midonet.org
> >> >>> http://lists.midonet.org/listinfo/midonet
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> MidoNet mailing list
> >> >> MidoNet at lists.midonet.org
> >> >> http://lists.midonet.org/listinfo/midonet
> >> >>
> >> >
> >> >
> >> _______________________________________________
> >> MidoNet mailing list
> >> MidoNet at lists.midonet.org
> >> http://lists.midonet.org/listinfo/midonet
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet/attachments/20150630/4c24979d/attachment-0001.html>


More information about the MidoNet mailing list