[discuss] proposed approach to versioning

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[discuss] proposed approach to versioning

Joe Witt
All,

A while back we discussed following semantic versioning and that
seemed to be the prevailing view.

In my view, we've not followed it as precisely as we should.  It
communicates some important things to the community and users and
helps keep us honest with the impact that changes (both good and bad)
have on the community.

To help provide some clarity and establish a basis for continual
refinement and contribution of opinion I've started a wiki page for
it:

https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme

Thanks
Joe
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] proposed approach to versioning

Adam Taft
Joe,

I like where you're going with this.  As a point for discussion, one of the
confusing issues with NIFI releases is that they are "fat" in nature.
Almost any change anywhere could cascade up the tree to justify bumping the
minor if not major version number.  With the current fat model, you
probably almost never have a patch release (unless it's a critical one-off
security related issue), since almost any number of other feature worthy
changes have been included.

Semver.org is designed more for libraries, not distributions with multiple
bundles.  How do you reconcile this?  Should individual components live
purely in their own release history?  Or should the NIFI release versioning
continue to capture all of the changes everywhere and risk meaningless
version history.

I think of NIFI releases more in terms of a mini-Linux distribution.  You
have, for example, Foo-Linux which bundles:  kernel-4.0.1, openssh-6.7,
httpd-2.4.12, openjdk-7u62, glibc-2.19.  What release of Foo-Linux is this
exactly?  Semantic versioning doesn't strictly help answer this problem.

I would generally think it's better to have each individual component
released with its own version history, and then have a more "loose"
versioning for the overall release bundle.  Some lessons can definitely be
learned from Linux distros, since they have the same problem (on a bigger
scale).

Likely candidates for individual release modules, would include:

Processor/Service API
Framework
User Interface / REST API
Standard Processors Nar
Standard Controller Services Nar
Other (Apache) Extension Nars

Let each of these modules run in their own version context, and then have
your packaging be more about conveying significant feature milestones.  I
somewhat like what Redhat is doing (7.1, no patch level), but it's also
possible to use keywords (98, ME, XP, 7) or time periods (2015-1).

Adam



On Wed, Jun 3, 2015 at 5:03 PM, Joe Witt <[hidden email]> wrote:

> All,
>
> A while back we discussed following semantic versioning and that
> seemed to be the prevailing view.
>
> In my view, we've not followed it as precisely as we should.  It
> communicates some important things to the community and users and
> helps keep us honest with the impact that changes (both good and bad)
> have on the community.
>
> To help provide some clarity and establish a basis for continual
> refinement and contribution of opinion I've started a wiki page for
> it:
>
> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme
>
> Thanks
> Joe
>
Reply | Threaded
Open this post in threaded view
|

Re: [discuss] proposed approach to versioning

Joe Witt
Yeah im good with all that.  Would like to pursue that when we have a
registry for extensions.  The build is huge in bytes sense and not just in
a cascading version sense.  Though being that all components are part of
the same release version now im personally more concerned about the former
than the latter.  Registry for extensions relaxes both though.
On Jun 3, 2015 6:37 PM, "Adam Taft" <[hidden email]> wrote:

> Joe,
>
> I like where you're going with this.  As a point for discussion, one of the
> confusing issues with NIFI releases is that they are "fat" in nature.
> Almost any change anywhere could cascade up the tree to justify bumping the
> minor if not major version number.  With the current fat model, you
> probably almost never have a patch release (unless it's a critical one-off
> security related issue), since almost any number of other feature worthy
> changes have been included.
>
> Semver.org is designed more for libraries, not distributions with multiple
> bundles.  How do you reconcile this?  Should individual components live
> purely in their own release history?  Or should the NIFI release versioning
> continue to capture all of the changes everywhere and risk meaningless
> version history.
>
> I think of NIFI releases more in terms of a mini-Linux distribution.  You
> have, for example, Foo-Linux which bundles:  kernel-4.0.1, openssh-6.7,
> httpd-2.4.12, openjdk-7u62, glibc-2.19.  What release of Foo-Linux is this
> exactly?  Semantic versioning doesn't strictly help answer this problem.
>
> I would generally think it's better to have each individual component
> released with its own version history, and then have a more "loose"
> versioning for the overall release bundle.  Some lessons can definitely be
> learned from Linux distros, since they have the same problem (on a bigger
> scale).
>
> Likely candidates for individual release modules, would include:
>
> Processor/Service API
> Framework
> User Interface / REST API
> Standard Processors Nar
> Standard Controller Services Nar
> Other (Apache) Extension Nars
>
> Let each of these modules run in their own version context, and then have
> your packaging be more about conveying significant feature milestones.  I
> somewhat like what Redhat is doing (7.1, no patch level), but it's also
> possible to use keywords (98, ME, XP, 7) or time periods (2015-1).
>
> Adam
>
>
>
> On Wed, Jun 3, 2015 at 5:03 PM, Joe Witt <[hidden email]> wrote:
>
> > All,
> >
> > A while back we discussed following semantic versioning and that
> > seemed to be the prevailing view.
> >
> > In my view, we've not followed it as precisely as we should.  It
> > communicates some important things to the community and users and
> > helps keep us honest with the impact that changes (both good and bad)
> > have on the community.
> >
> > To help provide some clarity and establish a basis for continual
> > refinement and contribution of opinion I've started a wiki page for
> > it:
> >
> > https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme
> >
> > Thanks
> > Joe
> >
>