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