> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Remi Bergsma"
>> To: dev@cloudstack.apache.org
>> Sent: Tuesday, 12 January, 2016 19:04:55
>> Subject: Re: LTS release or not
>
>> Hi Lucian,
>>
>> Are you referring
Remi,
Yes, that, that's great then, thanks.
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
- Original Message -
> From: "Remi Bergsma"
> To: dev@cloudstack.apache.org
> Sent: Tuesday, 12 January, 2016 19:04:55
> Subject: R
>Lucian
>
>--
>Sent from the Delta quadrant using Borg technology!
>
>Nux!
>www.nux.ro
>
>- Original Message -
>> From: "Remi Bergsma"
>> To: dev@cloudstack.apache.org
>> Sent: Tuesday, 12 January, 2016 15:36:52
>> Subject: Re: LTS
About LTS.
Here are some of the Mesos releases:
+## Releases ##
+
+ * Apache Mesos 0.23.1 (2015-09-21)
+ * Apache Mesos 0.22.2 (2015-09-23)
+ * Apache Mesos 0.21.2 (2015-09-24)
+ * Apache Mesos 0.25.0 (2015-10-09)
+ * Apache Mesos 0.26.0 (2015-12-10)
quite frequent.
Anyone cares to check their
- Original Message -
> From: "Remi Bergsma"
> To: dev@cloudstack.apache.org
> Sent: Tuesday, 12 January, 2016 15:36:52
> Subject: Re: LTS release or not
> Hi,
>
> The method Daan describes can be done from 4.6 and on. It’s about merging a PR
> with a fix
Hi,
The method Daan describes can be done from 4.6 and on. It’s about merging a PR
with a fix, and forward merging it. Not about actually releasing immediately.
If the bug has always been there, one would merge to 4.6, merge forward to
newer releases (and finally master) and then back port (ak
Depending on how far back the problem originated, this may not be
practical.
The code might have been massaged many times or code may have been
written that depends on the buggy behaviour.
If the bug "was always there" but no one had figured out the exploit, it
might not be possible to identif
ok, one last €0,01: any bug should be fixed not on the branch but on the
commit it was introduced in and thenn be merged forward. It can then be
merged into any branch that contains the offending commit and there is no
longer any difference between LTS or anything else. Am I speaking
Kardeshian? I
There are good points for and against LTS. I do have specific use case
that LTS solves, but in my opinion the scope of LTS would need to be
revised.
Why LTS is good idea?
If you have environment with thousands of servers, upgrading from 4.5 to
4.7 and beyond would be rather risky. There are instan
There may have to be some rules about patches such as
"You may not apply any bug fix to a minor release that will break the
upgrade path."
So 4.6.0, 4.6.1 and 4.6.2 can all be upgraded to 4.7.0 or the latest 4.7.x
If a user absolutely needs a fix that breaks this, then it is their
problem to up
Hi René,
Yes, except there’s nothing in CloudStack that can handle such a version and
I’m unsure if the extra dot works. If you call it 4.5.2-1 it works. You could
only give the package a new version and then re-release 4.5.2. Although that
probably is not compatible with the Apache release pro
Hi Remi
On 01/11/2016 04:16 PM, Remi Bergsma wrote:
> Maintaining LTS is harder than it seems. For example with upgrading. You can
> only upgrade to versions that are released _after_ the specific LTS version.
> This due to the way upgrades work. If you release 4.7.7 when we’re on say
> 4.10, y
e and LTS maintenance should be
> much easier as the upstream ( 4.7+) gets the benefit of the new workflow.
> >
> >
> >
> >
> >> --
> >> Sent from the Delta quadrant using Borg technology!
> >>
> >> Nux!
> >> www.nux.ro
> >>
&g
as the upstream ( 4.7+) gets the benefit of the new workflow.
>
>
>
>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>>> From: "Daan Hoogland"
>&g
; --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
> >
> > ----- Original Message -
> >> From: "Daan Hoogland"
> >> To: "dev"
> >> Sent: Monday, 11 January, 2016 13:36:06
&
he new workflow.
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Daan Hoogland"
>> To: "dev"
>> Sent: Monday, 11 January, 2016 13:36:06
>> Subject
; From: "Daan Hoogland"
> To: "dev"
> Sent: Monday, 11 January, 2016 13:36:06
> Subject: Re: LTS release or not
> Any version that is not a year old should be LTS in my view. We must as
> reviewers take care that fixes are merged on the oldest branch first and
>
On 01/11/2016 02:28 PM, Nux! wrote:
> What lifetime are we talking rougly for an LTS release? 6 months, 12 months?
I thought about 18 months. After 12 months we define a new LTS.
So users have a 6 months time frame to switch from LTS to LTS.
using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Daan Hoogland"
> > To: "dev"
> > Sent: Monday, 11 January, 2016 13:19:48
> > Subject: Re: LTS release or not
>
> > On Mon, Jan 11, 2016 at 7:58 A
n LTS release? 6 months, 12 months?
Lucian
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
- Original Message -
> From: "Daan Hoogland"
> To: "dev"
> Sent: Monday, 11 January, 2016 13:19:48
> Subject: Re: LTS release or not
> On
On Mon, Jan 11, 2016 at 7:58 AM, Rene Moser wrote:
> >> * Fix must be important.
> >>
> >
> > Who defines what 'important' is?
>
> "must be important" means we do not backport trivial things like typos
> in docs and so forth, only important things. And I would say important
> in a common sense. B
On 01/10/2016 11:46 PM, Erik Weber wrote:
> What if the fix is part of a refactorization or a new feature?
> Providing a LTS is not 'easy as pie' with a product like CloudStack where a
> lot of code changes over time.
Didn't say it's easy :)
Yes re-factorization is one of the unsolved "problem
On Sun, Jan 10, 2016 at 10:27 PM, Rene Moser wrote:
>
> On 01/10/2016 10:07 PM, Wido den Hollander wrote:
> > Ok, understood. However, it will be up to users on their own to pick
> > this LTS maintainment up.
>
> It would be up to the devs making fixes small (so no squashing for
> fixes) and noti
On 01/10/2016 10:07 PM, Wido den Hollander wrote:
> Ok, understood. However, it will be up to users on their own to pick
> this LTS maintainment up.
It would be up to the devs making fixes small (so no squashing for
fixes) and notify the one maintaining the LTS version if they feel the
fix is tha
On 01/10/2016 09:58 PM, Rene Moser wrote:
> Hi Wido
>
> On 01/10/2016 08:23 PM, Wido den Hollander wrote:
>> I personally am against LTS versions. If we keep the release cycle short
>> enough each .1 increment in version will only include a very small set
>> of features and bug fixes.
>>
>> In t
Daan
Have not yet decided which version, but fixes will be backported into
LTS not the other way around.
But I see what you mean. The code base may have much diverted before 4.7
right?
It is not really a problem. It only means more work (argh...). Sooner or
later this will happen for every relea
Hi Wido
On 01/10/2016 08:23 PM, Wido den Hollander wrote:
> I personally am against LTS versions. If we keep the release cycle short
> enough each .1 increment in version will only include a very small set
> of features and bug fixes.
>
> In the old days it took months for a release, if we bring
On 01/09/2016 11:51 PM, Rene Moser wrote:
> Hi
>
> I recently started a discussion about the current release process. You
> may have noticed that CloudStack had a few releases in the last 2 months.
>
> My concerns were that many CloudStack users will be confused about these
> many releases (whi
Rene, I would advice to support 4.7 as LTS. It adheres to the new
development/release process unlike 4.5 and any bugfixes there can
automatically be merged forward to newer releases to reduce the chance of
regression.
I am in favour of the general concept.
On Sun, Jan 10, 2016 at 12:12 AM, Rubens
Hi
I recently started a discussion about the current release process. You
may have noticed that CloudStack had a few releases in the last 2 months.
My concerns were that many CloudStack users will be confused about these
many releases (which one to take? Are fixes backported? How long will it
rec
30 matches
Mail list logo
