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" <[email protected]> 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 <[email protected]> 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 > > >
