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 <don...@apache.org> 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 <don...@apache.org> 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 <p...@occamsmachete.com> > 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 < >> paularmand.verhae...@gmail.com> 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 <p...@actionml.com> 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. >> >> >> >
