storm-mesos versioning

[mesos]

storm-mesos versioning

[DarinJ]

@erikdw I like the maven artifact: storm-mesos-0.1.0-storm0.9.6.jar and build package: storm-mesos-0.1.0-storm0.9.6.tar.gz, it would really help with keeping track of framework version vs storm version.

I'm not certain I care about the Mesos version, but it wouldn't hurt. I am pro making mesos-version an option in the build-release though as don't like editing pom files to change the version.

I don't mind making the changes in my PR as it will make it more coherent. I submitted a WIP to facilitate the conversation.

Should we start at 0.1.0? It seems odd to go backwards in version numbers.

[brndnmtthws]

👍 from me.

For the Docker automated builds, we can build automatically from tags and branches.

[echinthaka]

+1 for the maven artifact naming scheme, but my only concern is would this be troublesome since we have to maintain support for multiple versions of storm and mesos at a given point of time?
For example, the moment one of these deps become backward incompatible, then our code AND the build system will be complex. Hence, would it makes sense to support only one storm version with the latest release? Just thinking aloud

[JessicaLHartog]

I'm in favor of the proposed:
storm-mesos-0.1.0-storm0.9.6-mesos0.25.0.tar.gz style naming because:

1. Changes that are made to this project that are related to storm-version specifics may determine whether or not this project will run in a given setup (see issue #68 as an example)
2. Changes that are made to this project that are related to mesos-version specific have already happened (for example which is related to MESOS-1807 which will force behavior in future releases) -- now it just so happens that the previous changes were backwards compatible, but there is high probability that there will be further non-backwards compatible changes.

Since we depend on both storm versions and mesos versions -- it seems to make sense that we include both in our conventions.

Because that's a lot of dependencies and versioning, perhaps we can limit it to a maximum of two versions each of storm and mesos -- or alternatively only support two versions of either dependency when there are major non-backwards compatible changes, giving people time to adopt the new changes and then falling back to support for only a single version of storm and mesos after a time?

[erikdw]

@echinthaka : yup, I hear you that it could become an unseemly burden to support multiple versions. But I wanna maintain support if it's relatively trivial to build against 0.10.0 and 0.9.x, which @DarinJ's change aims to provide (haven't had time to review it yet).

Notably, today this project doesn't even declare which version of storm are supported. Until #77, the project will only work against 0.9.x I believe (maybe earlier versions, not sure, have never used them).

Storm 0.10.0 is a major change from 0.9.x. It's got "crazy lots" of stuff in it, and I'm nowhere near being ready to upgrade to it, so I definitely don't wanna drop 0.9.x support for many months. But I don't wanna hold back people from using 0.10.0 if they can.

[erikdw]

@brndnmtthws : cool, and that would somehow add the metadata into the Dockerhub build/image list, and also allow us to specify the version/tag in our mesos.container.docker.image config field? (I'm confused by the lack of info in the Dockerhub interface.)

[erikdw]

@JessicaLHartog : thanks for the examples and references. And yes, I don't think we need to make superhuman efforts to be perfectly compatible as the landscape shifts. I just really want the storm 0.9.x stuff to continue working for awhile at least. I'm less scared about upgrading mesos. ;-)

[erikdw]

@DarinJ : thanks for PR #77. And sure, your PR seems a natural place to introduce this version scheme. Regarding the initial version: sure, 0.1.0 seems reasonable, we can follow semantic versioning (semver) if we feel ambitious.

[erikdw]

With PR #77 landing we now have the groundwork in place to implement this versioning scheme. I will leave this (issue #76) open for the moment in order to leave a cookie crumb pointing to commits for releasing the "first version" when I spend some time on that.

[salimane]

@erikdw , awesome .

It would now be doubly awesome to just go to https://github.com/mesos/storm/releases and download releases build based storm version, mesos versions and storm-mesos versions :)

Thanks

[erikdw]

Thanks to @salimane for the contribution of #117 which allows us to automatically upload releases by .

Since we don't yet have the ability to use the mvn release plugin, I've taken the following steps to release v0.1.0:

1. Prepared for v0.1.0 release by modifying project.version and project.parent.version in pom.xml files from 0.1.0-SNAPSHOT to 0.1.0
2. Merged that PR to the mesos/storm master branch
3. Created a release on the mesos/storm release page
   • Notably, I used v0.1.0 instead of 0.1.0, in compliance with the suggestion on the right hand side
4. Prepared for next development iteration by updating pom.xml versions to 0.1.1-SNAPSHOT