Re: [Gluster-Maintainers] Proposal to change the version numbers of Gluster project

[Vijay Bellur]

On Tue, Mar 13, 2018 at 4:25 AM, Kaleb S. KEITHLEY 
wrote:

> On 03/12/2018 02:32 PM, Shyam Ranganathan wrote:
> > On 03/12/2018 10:34 AM, Atin Mukherjee wrote:
> >>   *
> >>
> >> After 4.1, we want to move to either continuous numbering (like
> >> Fedora), or time based (like ubuntu etc) release numbers. Which
> >> is the model we pick is not yet finalized. Happy to hear
> opinions.
> >>
> >>
> >> Not sure how the time based release numbers would make more sense than
> >> the one which Fedora follows. But before I comment further on this I
> >> need to first get a clarity on how the op-versions will be managed. I'm
> >> assuming once we're at GlusterFS 4.1, post that the releases will be
> >> numbered as GlusterFS5, GlusterFS6 ... So from that perspective, are we
> >> going to stick to our current numbering scheme of op-version where for
> >> GlusterFS5 the op-version will be 5?
> >
> > Say, yes.
> >
> > The question is why tie the op-version to the release number? That
> > mental model needs to break IMO.
> >
> > With current options like,
> > https://docs.gluster.org/en/latest/Upgrade-Guide/op_version/ it is
> > easier to determine the op-version of the cluster and what it should be,
> > and hence this need not be tied to the gluster release version.
> >
> > Thoughts?
>
> I'm okay with that, but——
>
> Just to play the Devil's Advocate, having an op-version that bears some
> resemblance to the _version_ number may make it easy/easier to determine
> what the op-version ought to be.
>
> We aren't going to run out of numbers, so there's no reason to be
> "efficient" here. Let's try to make it easy. (Easy to not make a mistake.)
>
> My 2¢
>
>
+1 to the overall release cadence change proposal and what Kaleb mentions
here.

Tying op-versions to release numbers seems like an easier approach than
others & one to which we are accustomed to. What are the benefits of
breaking this model?

Thanks,
Vijay
___
maintainers mailing list
maintainers@gluster.org
http://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] Proposal to change the version numbers of Gluster project

[Kaleb S. KEITHLEY]

On 03/12/2018 02:32 PM, Shyam Ranganathan wrote:
> On 03/12/2018 10:34 AM, Atin Mukherjee wrote:
>>   *
>>
>> After 4.1, we want to move to either continuous numbering (like
>> Fedora), or time based (like ubuntu etc) release numbers. Which
>> is the model we pick is not yet finalized. Happy to hear opinions.
>>
>>
>> Not sure how the time based release numbers would make more sense than
>> the one which Fedora follows. But before I comment further on this I
>> need to first get a clarity on how the op-versions will be managed. I'm
>> assuming once we're at GlusterFS 4.1, post that the releases will be
>> numbered as GlusterFS5, GlusterFS6 ... So from that perspective, are we
>> going to stick to our current numbering scheme of op-version where for
>> GlusterFS5 the op-version will be 5?
> 
> Say, yes.
> 
> The question is why tie the op-version to the release number? That
> mental model needs to break IMO.
> 
> With current options like,
> https://docs.gluster.org/en/latest/Upgrade-Guide/op_version/ it is
> easier to determine the op-version of the cluster and what it should be,
> and hence this need not be tied to the gluster release version.
> 
> Thoughts?

I'm okay with that, but——

Just to play the Devil's Advocate, having an op-version that bears some
resemblance to the _version_ number may make it easy/easier to determine
what the op-version ought to be.

We aren't going to run out of numbers, so there's no reason to be
"efficient" here. Let's try to make it easy. (Easy to not make a mistake.)

My 2¢

--

Kaleb
___
maintainers mailing list
maintainers@gluster.org
http://lists.gluster.org/mailman/listinfo/maintainers

Re: [Gluster-Maintainers] Proposal to change the version numbers of Gluster project

[Atin Mukherjee]

On Mon, Mar 12, 2018 at 5:51 PM, Amar Tumballi  wrote:

> Hi all,
>
> Below is the proposal which most of us in maintainers list have agreed
> upon. Sharing it here so we come to conclusion quickly, and move on :-)
>
> ---
>
> Until now, Gluster project’s releases followed x.y.z model, where x is
> indicating a major revision, and y a minor, and z as a patched release.
> Read more on this model at wikipedia
> 
>
> As we are announcing the release and availability of Gluster 4.0[.0] now,
> it is a good time to reconsider our version numbering.
>
> What
> is the need to reconsider version number now?
>
> The major and minor version numbering is a good strategy for projects
> which would bring incompatibility between major versions.
>
> For Gluster, as it is a filesystem, and one of the major reason people use
> this project is because of ‘High Availability’, we can never think of
> breaking compatibility between releases. So, regardless of any major
> version changes, the filesystem should continue to work from a given mount
> point.
>
> *NOTE*: We are not saying there will be no issues ever for clients at
> all, but users will have enough time to plan, based on called out
> incompatabilities, and hence adapt to the new changes in an application
> maintenance window.
>
> Also, this allows us to bring features and changes frequently, and not
> wait for the major version number change to make a release.
> So, what next?
>
> There are multiple changes we are proposing.
>
>-
>
>As announced earlier 4.0 will be STM, and it will be the last STM.
>-
>
>As we had already announced, 4.1 will be our LTM (Long Term
>Maintenance) release. This will release 3 months from 4.0 (June, 2018 end)
>-
>
>After 4.1, we want to move to either continuous numbering (like
>Fedora), or time based (like ubuntu etc) release numbers. Which is the
>model we pick is not yet finalized. Happy to hear opinions.
>
>
Not sure how the time based release numbers would make more sense than the
one which Fedora follows. But before I comment further on this I need to
first get a clarity on how the op-versions will be managed. I'm assuming
once we're at GlusterFS 4.1, post that the releases will be numbered as
GlusterFS5, GlusterFS6 ... So from that perspective, are we going to stick
to our current numbering scheme of op-version where for GlusterFS5 the
op-version will be 5?


>
>-
>
>There will be no more STM releases for early access, still to mature
>features. We will either use the experimental branch, or tag a feature
>in a release as experimental. Everything core to the operation of Gluster,
>will remain stable and will only improve from release to release.
>
> *NOTE:* Exact mechanisims for tagging something experimental Vs stable is
> being evolved. Further, what this means for a user is also being evovled
> and will be put out for discussion soon.
>
>-
>
>Considering we had 6 months release cycle for LTM releases, and 3
>months for branching, we want to fall back to 4 months release cycle for
>different versions, so we will cut down on number of backports, and
>supported versions from which we can upgrade to latest. Also users will
>benefit from more releases which are going to be supported long term.
>-
>
>Every release will be maintained for 1 year as earlier
>- Monthly bug fixs per maintained release would be made available (as
>   before) (update releases)
>   - Post the first 3 or 4 months, for monthly bug fix update
>   releases, the cycle will change to bi-monthy (once in 2 months) or
>   expidated as necessary
>
> ---
>
> Happy to hear your opinion.
>
>
> Regards,
> Amar
>
>
> ___
> maintainers mailing list
> maintainers@gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>
>
___
maintainers mailing list
maintainers@gluster.org
http://lists.gluster.org/mailman/listinfo/maintainers