You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@predictionio.apache.org by Pat Ferrel <pa...@actionml.com> on 2016/11/25 17:57:23 UTC
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 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.
Re: Micro-releases
Posted by Donald Szeto <do...@apache.org>.
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 <an...@gmail.com>
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 <pa...@occamsmachete.com> 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 <pa...@occamsmachete.com> 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 <do...@apache.org> 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 <pa...@occamsmachete.com>
> 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 <do...@apache.org> 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 <pa...@occamsmachete.com>
>
> >> 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 <do...@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 <do...@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 <pa...@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.verhaegen@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 <pa...@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.
>
> >>>>>
>
> >>>>>
>
> >>>>>
>
> >>>>
>
> >>>
>
> >>>
>
> >>
>
> >>
>
> >
>
> >
>
>
Re: Micro-releases
Posted by Andrew Purtell <an...@gmail.com>.
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 <pa...@occamsmachete.com> 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 <pa...@occamsmachete.com> 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 <do...@apache.org> 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 <pa...@occamsmachete.com> 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 <do...@apache.org> 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 <pa...@occamsmachete.com>
>> 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 <do...@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 <do...@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 <pa...@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.verhaegen@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 <pa...@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.
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: Micro-releases
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 <pa...@occamsmachete.com> 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 <do...@apache.org> 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 <pa...@occamsmachete.com> 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 <do...@apache.org> 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 <pa...@occamsmachete.com>
> 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 <do...@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 <do...@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 <pa...@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.verhaegen@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 <pa...@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.
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Re: Micro-releases
Posted by Pat Ferrel <pa...@occamsmachete.com>.
@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 <do...@apache.org> 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 <pa...@occamsmachete.com> 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 <do...@apache.org> 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 <pa...@occamsmachete.com>
> 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 <do...@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 <do...@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 <pa...@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.verhaegen@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 <pa...@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.
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
Re: Micro-releases
Posted by Donald Szeto <do...@apache.org>.
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 <pa...@occamsmachete.com> 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 <do...@apache.org> 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 <pa...@occamsmachete.com>
> 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 <do...@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 <do...@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 <pa...@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.verhaegen@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 <pa...@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.
> >>>
> >>>
> >>>
> >>
> >
> >
>
>
Re: Micro-releases
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 <do...@apache.org> 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 <pa...@occamsmachete.com> 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 <do...@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 <do...@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 <pa...@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.verhaegen@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 <pa...@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.
>>>
>>>
>>>
>>
>
>
Re: Micro-releases
Posted by Donald Szeto <do...@apache.org>.
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 <pa...@occamsmachete.com> 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 <do...@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 <do...@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 <pa...@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.verhaegen@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 <pa...@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.
> >>
> >>
> >>
> >
>
>
Re: Micro-releases
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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 <do...@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 <do...@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 <pa...@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.verhaegen@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 <pa...@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.
>>
>>
>>
>
Re: Micro-releases
Posted by Donald Szeto <do...@apache.org>.
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 <do...@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 <pa...@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.verhaegen@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 <pa...@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.
>>
>>
>>
>
Re: Micro-releases
Posted by Donald Szeto <do...@apache.org>.
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 <pa...@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-
> successful-git-branching-model/ <http://nvie.com/posts/a-
> successful-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.verhaegen@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 <pa...@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.
>
>
>
Re: Micro-releases
Posted by Pat Ferrel <pa...@occamsmachete.com>.
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/ <http://nvie.com/posts/a-successful-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 <pa...@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 <pa...@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.
Re: Micro-releases
Posted by Paul-Armand Verhaegen <pa...@gmail.com>.
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 <pa...@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.