cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Johnson <njohn...@ena.com.INVALID>
Subject Re: questions about 4.11 future
Date Mon, 07 Jan 2019 15:13:57 GMT


> On Jan 4, 2019, at 10:18 AM, Wei ZHOU <ustcweizhou@gmail.com> wrote:
> 
> Hi Nathan,
> 
> You can use ConfigKey instead of mysql change in cloudstack.

Ahh!  I had no idea these worked this way.  Thanks!  This makes matters much easier.

Nathan

> 
> -Wei
> 
> Nathan Johnson <njohnson@ena.com.invalid> 于2019年1月3日周四 下午5:10写道:
> 
>> 
>> 
>>> On Jan 3, 2019, at 9:50 AM, Rafael Weingärtner <
>> rafaelweingartner@gmail.com> wrote:
>>> 
>>> I have a question. Is it a bug or a feature?
>> 
>> That is a very good question, and up for interpretation.  Please feel free
>> to weigh in here:
>> 
>> https://github.com/apache/cloudstack/issues/3096
>> 
>> 
>> 
>>> 
>>> I have seen new features being introduced in this 4.11 (LTS) version,
>> and I
>>> keep asking myself, why do we do that?
>>> According to the LTS document we have, LTS versions should only receive
>>> fixes, and not new features.
>>> 
>>>> The following are the types of changes that are permitted and guarantees
>>>> provided to users:
>>>> 
>>>>  - Defect fixes only.  Enhancements for that expand support for
>>>>  existing plugins (e.g. XenServer 7) and additional JDK/JRE or MySQL
>>>>  versions may be considered if the change is sufficiently isolated and
>> do
>>>>  not introduce significant quality release to the branch.
>>>>  - Database changes will be limited to those required to address defect
>>>>  fixes
>>>>  - Supported JDK/JRE, MySQL, and Linux distribution versions will not
>>>>  be removed throughout the cycle
>>>> 
>>>> Reference: https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>>> 
>>> On Thu, Jan 3, 2019 at 1:44 PM Paul Angus <paul.angus@shapeblue.com>
>> wrote:
>>> 
>>>> There definitely will be a 4.11.3 release, I would expect it to be
>> around
>>>> end of Q1.
>>>> We shouldn't have a problem handling a new unique entry in both with an
>>>> INSERT IGNORE in the 4.12 upgrade script
>>>> 
>>>> 
>>>> Kind regards,
>>>> 
>>>> Paul Angus
>>>> 
>>>> paul.angus@shapeblue.com
>>>> www.shapeblue.com
>>>> Amadeus House, Floral Street, London  WC2E 9DPUK
>>>> @shapeblue
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Simon Weller <sweller@ena.com.INVALID>
>>>> Sent: 03 January 2019 15:23
>>>> To: Rohit Yadav <rohit.yadav@shapeblue.com>; dev@cloudstack.apache.org
>>>> Subject: Re: questions about 4.11 future
>>>> 
>>>> Rohit,
>>>> 
>>>> 
>>>> Thoughts on this? We can base it on 4.11 or the pending 4.12 master.
>>>> 
>>>> 
>>>> - Si
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ________________________________
>>>> From: Nathan Johnson <njohnson@ena.com.INVALID>
>>>> Sent: Wednesday, January 2, 2019 12:23 PM
>>>> To: Rohit Yadav
>>>> Cc: dev@cloudstack.apache.org
>>>> Subject: questions about 4.11 future
>>>> 
>>>> First off, is there going to be a 4.11.3 release?
>>>> 
>>>> Assuming so, at what point would it be appropriate to add database
>>>> migrations?  I have a bug fix I'd like to open a PR on, but it will
>> require
>>>> a small database change - namely inserting a record into the
>> configuration
>>>> table.
>>>> 
>>>> Is it appropriate for me to start a new migration path for 4.11.3 to
>>>> facilitate this fix?  Or would it be more appropriate for the release
>>>> manager to do this?
>>>> 
>>>> If you'd like, I have a 4.11.3 database migration started in my branch
>>>> (i.e., added a schema-41120to41130.sql / cleanup , added a
>>>> Upgrade41120to41130.java , and added the Upgrade41120to41130 class to
>> all
>>>> of the paths mentioned in DatabaseUpgradeChecker).  if you'd like me to
>>>> open a PR on effectively an empty 4.11.3 migrations path, and then I
>> could
>>>> make a second PR that just adds the appropriate sql statement(s) for the
>>>> actual bug fix PR.
>>>> 
>>>> Thanks in advance,
>>>> 
>>>> Nathan Johnson
>>>> 
>>> 
>>> 
>>> --
>>> Rafael Weingärtner
>> 
>> 


Mime
View raw message