The version number looks fine. Like Andrew said I think the only thing that matters is that we don't advertise these as official releases.
Thanks for driving this Pat! On Thu, Dec 15, 2016 at 7:13 PM Andrew Purtell <[email protected]> wrote: > How you manage source control is pretty much up to you. The key is to > clearly tag commits that correspond to releases and only advertise those > and their binary and/or source artifacts as official project releases. I > think that will cover it. > > > > > > > On Dec 14, 2016, at 4:16 PM, Pat Ferrel <[email protected]> wrote: > > > > > > Assuming the mentors see no problem with this. I’ll start a hotfix > branch from master, merge the fix with it and then into master (it’s > already in develop). I’ll add a .1 to the artifacts so they will be > 0.10.0-incubating.1 This will be documented in the appropriate places but > only visible if you pull from master. it will not trigger a new release. > Please remember that master is not our SNAPSHOT branch as explained below. > > > > > > speak soon or... > > > > > > > > > On Dec 14, 2016, at 4:11 PM, Pat Ferrel <[email protected]> wrote: > > > > > > @Mentors > > > > > > We are discussing creating a “hotfix” branch from which we will merge > into development as well as master. > > > > > > These hotfixes are an agile way to fix serious problems in the master > where we maintain a stable non-SNAPSHOT version. I did not see this as a > release with a tarball into the nexus-verse. The key thing about these is > that we do not put experimental “SNAPSHOT” code into master as do many > other Apache projects. So merging hotfixes into master would give users a > way to retrieve a fairly stable fix with none of the more experimental code > in develop. > > > > > > So keeping the context in mind I would imagine recommending people > upgrade to the hotfix version, otherwise why put it in master—given our > care about keeping master stable. > > > > > > This is not an academic question because we now have at least one > serious bug fix waiting for the hotfix part of the process. It is not > enough to trigger a full merge of the develop branch since develop is not > ready yet and is too serious to wait for a full release. > > > > > > To see the process we’d like to follow please have a look at: > http://nvie.com/posts/a-successful-git-branching-model/ This model has a > great deal to recommend it and has been used in PIO for some time. We have > already agreed to follow this model, now we are discussing logistics. > > > > > > > > > On Dec 5, 2016, at 9:03 AM, Donald Szeto <[email protected]> wrote: > > > > > > I am okay with reserving patch for official releases, and use suffix that > > > have something with an increasing numerical in it. > > > > > > We will probably need a dedicated page or micro site in the doc for these > > > kind of unofficial tar balls. It is against ASF policy to mark anything > as > > > release and encourage people to use without the formal voting process. > They > > > also cannot be sync to ASF distribution. > > > > > >> On Thu, Dec 1, 2016 at 10:25 AM Pat Ferrel <[email protected]> > wrote: > > >> > > >> But the downside is we never touch major, or haven’t in all the years of > > >> PIO. So in effect all releases will be minor number changes and so far > we > > >> have only touched that 10 times in all the years of PIO. We could skip > many > > >> patch numbers and only fully release on important ones. But Semantic > > >> Versioning 2.0 allows a lot of other encoding of minor information in > the > > >> hyphen extension like dot numbers, beta, RC, incubating etc. > > >> http://semver.org/#spec-item-9 <http://semver.org/#spec-item-9> They > > >> account for things as crazy as 1.0.0-x.7.z.92. > > >> > > >> I guess I’m ok with either skipping a lot of patch numbers per actual > > >> release and only using patch numbers to denote hotfixes or adding > something > > >> to the hyphen extension but limiting release numbers to something as > course > > >> grained as major and minor seems problematic. > > >> > > >> And yet if everyone likes this so be it. > > >> > > >> On Dec 1, 2016, at 10:05 AM, Donald Szeto <[email protected]> wrote: > > >> > > >> Yes. I was suggesting to use 0.10.1-incubating. The upside of this is > that > > >> our end users know which one has included all the latest fix instead of > > >> tracking different JIRA ticket numbered suffices. We can limit real > > >> releases to touch only major and minor version parts. > > >> > > >> On Mon, Nov 28, 2016 at 10:26 AM, Pat Ferrel <[email protected]> > > >> wrote: > > >> > > >>> Good point (reliable building). An extension of strict semantic > > >> versioning > > >>> allows an extension like -incubating, this could include a Jira # too > so > > >>> the full artifact name might be: > > >>> > > >>> org.apache.predictionio-0.10.0-incubating-jira-255 and this would be > > >>> tagged jira-255 in either hotfix of master branches. > > >>> > > >>> This allows the docs to remain unchanged because the version 0.10.0 > does > > >>> not change, which we might reserve for real releases. Donald are you > > >>> suggesting a new 0.10.1-incubating for each hotfix? > > >>> > > >>> > > >>> On Nov 28, 2016, at 10:18 AM, Donald Szeto <[email protected]> wrote: > > >>> > > >>> We should also talk about how we proceed with versioning these patch > > >>> releases. We follow semantic versioning, so naturally we could use > major > > >>> and minor portions for official releases, and the patch portion for > > >>> micro-releases / hotfixes. This way, even though Maven artifacts won't > be > > >>> published to the central repository, users will not get tripped with > > >>> different cached versions of the artifacts. > > >>> > > >>> On Mon, Nov 28, 2016 at 10:14 AM, Donald Szeto <[email protected]> > > >> wrote: > > >>> > > >>>> Pat's link is the best description of the Git development model that > > >>>> PredictionIO has been using since the beginning. I also support the > use > > >>> of > > >>>> hotfix branches that will merge into both master and develop branches. > > >>>> > > >>>> Branching for different sets of external dependencies, in my opinion, > > >>>> should be the last resort. We can try to work our build system to > > >>>> accommodate. > > >>>> > > >>>> When we have a conclusion we should update http://predictionio. > > >>>> incubator.apache.org/community/contribute-code/ > > >>>> > > >>>> On Sat, Nov 26, 2016 at 10:00 AM, Pat Ferrel <[email protected]> > > >>>> wrote: > > >>>> > > >>>>> This is a better description of how we should be managing code and > git > > >>>>> branches than I have every seen: http://nvie.com/posts/a-succes > > >>>>> sful-git-branching-model/ <http://nvie.com/posts/a-succe > > >>>>> ssful-git-branching-model/> It includes the use of develop, a stable > > >>>>> master branch, and hotfixes to master. I also like more than one > > >> release > > >>>>> branch because I imagine once we support two versions of > Elasticsearch > > >>> or > > >>>>> Spark that require code changes, a branch is the natural way to > > >> assemble > > >>>>> the code. > > >>>>> > > >>>>> The post is worth a read and discussion. My other Apache git based > > >>>>> project could use this approach too. > > >>>>> > > >>>>> In this case I’m only proposing that major bug fixes (hotfixes) be > > >>>>> allowed into master and be tagged. The post gives good rationale for > > >>> this. > > >>>>> > > >>>>> > > >>>>> On Nov 25, 2016, at 11:30 PM, Paul-Armand Verhaegen < > > >>>>> [email protected]> wrote: > > >>>>> > > >>>>> > > >>>>> Great proposal. I certainly agree with the needs in the community and > > >>>>> associated benefits for fast bug fixes in master. > > >>>>> If I may suggest to hotfix against master with merge towards > > >>> development. > > >>>>> Merges can be cumbersome when dev and master diverge. > > >>>>> It can become very difficult if the fixes (from dev) cannot be > applied > > >>> to > > >>>>> master, and additional commits need to be made, that has messed up my > > >>> head > > >>>>> before. > > >>>>> Although more or less the same work, I believe it to be less of an > > >> issue > > >>>>> if we end up messing up dev. > > >>>>> I'm also in favor of using a well-documented approach such as > gitflow, > > >>>>> since I often forget the exact workflows of different projects. > > >>>>> > > >>>>>> On 25 Nov 2016, at 18:57, Pat Ferrel <[email protected]> wrote: > > >>>>>> > > >>>>>> Our dev process includes edge/snapshot code being kept in the > develop > > >>>>> branch until release time. I like this process because it allows us > to > > >>> keep > > >>>>> master clean and stable. So imagine that we have a major bug fix. To > > >> get > > >>>>> this to users we could do a release but this can’t happen soon enough > > >>> if a > > >>>>> user has discovered it and already needs the fix. We could point to a > > >>>>> commit in develop but that branch is a little wild until release > time. > > >>>>>> > > >>>>>> I’d like to propose we allow some commits to master, to fix critical > > >>>>> bugs, and tag these with the Jira # describing the bug. The fix would > > >>> also > > >>>>> go in develop so at merge time there would be nothing to merge. > > >>>>>> > > >>>>>> At present we have a source only release so this would work fairly > > >>>>> well, even with a binary release it would be safer and easier to > > >>> document > > >>>>> than suggesting a build of the develop branch. > > >>>>>> > > >>>>>> Opinions? If no one objects there was a critical bug fixed recently > > >> and > > >>>>> I’ll do the above to get the fix in master. > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>> > > >>> > > >> > > >> > > > > > > > >
