Re: Micro-releases

-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 >>

Re: Micro-releases

; >> 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 off

Re: Micro-releases

t 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 > &

Re: Micro-releases

fix? > > > 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,

Re: Micro-releases

o 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 repo

Re: Micro-releases

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

Re: Micro-releases

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

Re: Micro-releases

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-successful-git-branching-model/ It includes the use of develop, a stable master branch, and hotfixes to

Re: Micro-releases

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

Micro-releases

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