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 >
