To me, if we would like to offer LTS, we need to fix following core issues: - how database version is handle, right now database structure is mixed with upgrade*.sql files and some java code - better test upgrade path, I'm not sure we test them properly :-S
I have to admit I'm not fan of LTS release and would probably be -1, on this for the following reasons: Over the last year of so we start bumping old branch sub-release to back port bugfixes, the idea is not bad, but we are now facing issues that Upgrade paths are broken because older branch minor releases can be more recent than latest main release as result as database consistency. last example: 4.8.1 will be release after 4.9.0 A problematic issue that we are experiencing is the database structure, we currently have a scenario in our infra where a fresh installation of 4.7.2 does not have the same `configuration` table content as an older system that have that path: 4.4.0 -> 4.4.4 -> 4.7.0 -> 4.7.2 I blame our database versioning method, and the fact that we are changing upgrade_*.sql files between releases. The reality is that once release package are voted, we should never change update*.sql files except for the next coming version that as not been released yet. Rohit discussed about solution about this in the past, we should review that. Another issue we are seeing, that our personal experience at keep using an old branch, is the complexity of submitting bug fixes that require 2 code fixes if the main code diverge too much, back porting bug fixes or new features is not trivial sometime because the code base change too much between versions. This is not really inviting to submit bug fixes. So now regression tests are event more complicated because a bug can be fixed in an older branch but not in master due to code refactor, or missing PR or merge. Also, keeping users in previous branch prevent them to use latest hypervisors releases (XenServer 7.0) and latest Guest OSes (ex: Ubuntu 16.04). After running CloudStack for few years now, I found that remaining on an old branch/release is a medium term dead end, because you end up with inability to upgrade or use latest hypervisors and new guest OSes, upgrade path is much more complex and involve much more efforts than upgrading often as Shubberg proposed in the past. We have the capability to upgrade our software as oppose to similar projects, so we should leverage this. Last thing, I found the propose versioning is too complicated, why adding 5th and 6th digit, shouldn't we start bumping up 4.x.x to 5.x.x instead? I don't want to block any initiative going that path, LTS, but I'm a bit concerned in our current state and upgrade paths. Regards, Pierre-Luc On Wed, Aug 3, 2016 at 2:33 AM, Rajani Karuturi <raj...@apache.org> wrote: > The idea of maintaing the release branch longer can be discussed. > But, I am -1 for separate branches and separate release trains. > Maintaing the upgrade paths would be a big overhead. > We are not doing regular releases on the main release branches. > Rohit did a great job for 4.5(though it was backporting and not > forward merging at that time). Beyond that, we are not doing > regular releases. If we do regular updates on the release > branches, users who wish to take a release once in 6 months can > do so even now. It will just be current+6 release (assuming we do > regular minor releases every month) > ~ Rajanihttp://cloudplatform.accelerite.com/ > On August 3, 2016 at 4:07 AM, John Burwell > (john.burw...@shapeblue.com) wrote:Rajani, > As I mentioned in my previous email, the original motivation for > a completely separate branch was based on objections by some > community members that the longer, more conservative LTS release > cycle would place a drag on the velocity of regular > releases. Additionally, users interested in LTS releases voiced > their desire to have fewer releases a year. Therefore, where the > regular release cycle is scheduled to make major releases every 2 > months and maintenance releases every month, the LTS cycle makes > major releases every 6 months and maintenance releases less > frequently (e.g. every 3 months). These longer cycles allow > users with longer acceptance test/verification cycles to more > easily keep up with upgrades. Completely separate branches and > release cycles were proposed to serve both use cases (rapid, > leading upgrades and more traditional maintenance cycles). > I am open to collapsing LTS into the regular maintenance releases > (e.g. 4.9 simply becomes supported for 20 months instead of 4 > months). Ultimately, I would like that decision to be based on > user feedback since separate release branches/cycles have been > previously discussed with no objections [1]. I have CC’ed users@ > to solicit thoughts from our users on which approach would be > preferred. > Thanks,-John > [1]: http://markmail.org/thread/zh43rc6ahs4te46l ( > http://markmail.org/thread/zh43rc6ahs4te46l ) john.burw...@shapeblue.com > ( john.burw...@shapeblue.com > ) www.shapeblue.com ( http://www.shapeblue.com )53 Chandos > Place, Covent Garden, London VA WC2N 4HSUK@shapeblue > On Aug 2, 2016, at 3:57 AM, Rajani Karuturi <raj...@apache.org ( > raj...@apache.org )> wrote: > We already maintain the release branches and do > regularreleases(of the past two releases) on them. What are we > achievingthrough this LTS model? How is 4.9.1 different from > 4.9.0.0_1.0? > ~ Rajanihttp://cloudplatform.accelerite.com/On August 2, 2016 at > 2:33 AM, John Burwell(john.burw...@shapeblue.com ( > john.burw...@shapeblue.com )) wrote:Wido, > As proposed, LTS will be a branch of 4.9.0 with a six (6) > weekperiod of additional testing (i.e. soak/endurance, > scalability,and more extensive plugin testing). Therefore, LTS > releases willbe named <base release>_<LTS revision> meaning that > the first LTSrelease would be 4.9.0.0_1.0. The original > motivation for thisapproach was that the regular release cycle > performed testing fora week which was not enough time to execute > long running tests(e.g. the entire test suite requires roughly 4 > days to run, agood endurance/soak test should run for 5-7 > days,etc). Additionally, there was concern that LTS would impede > thevelocity of the regular release cycle. By decoupling > theregular and LTS release branches, there would be no > opportunityfor LTS constraints to impede velocity of the regular > releasecycle. > Since my original proposal, a number of aspects about the > releasecycle have changed. I am open to adjust LTS to simply be > anextension of the support period on the 4.9.0.0release. > Personally, I think the risk of the LTS cycle impedingregular > releases is very low. I also think it would be moreconsistent > with the way we have managed long running releases inthe past. We > would still perform the additional test we plannedfor LTS, but it > would on the 4.9 release branch rather than aseparate LTS branch. > Are there any objections to this change to the way LTS > branchesare managed and releases named? For now, I will leave the > LTSreleases in the schedule as defined in the originalproposal. > If/when we gain consensus on this change, I willadjust the > schedule. > Thanks,-John________________________________From: Wido den > Hollander<w...@widodh.nl ( w...@widodh.nl ) ( w...@widodh.nl ( > w...@widodh.nl ) )>Sent: Friday, July 15, 20164:15:36 > AMTo: dev@cloudstack.apache.org ( dev@cloudstack.apache.org > ) (dev@cloudstack.apache.org ( dev@cloudstack.apache.org ) ); > John BurwellSubject: Re: [PROPOSAL]Early LTS Initial ReleaseOp 13 > juli 2016 om 18:25 schreef John > Burwell<john.burw...@shapeblue.com ( john.burw...@shapeblue.com > ) ( john.burw...@shapeblue.com ( john.burw...@shapeblue.com ) )>: > All,Since LTS introduces a new release stream, I would like > topropose that we cut the first LTS quickly to verify that > variousaspects of the release cycle and version number > dependentcomponents will work properly with the new release > namingscheme. It will also allow us to flesh out distribution > issuessuch as download locations (e.g. for system VMs) and > publishingLTS documentation alongside regular releases. My > thinking isthat we would push an RC for this release within a > week of the4.9.0.0 release. If this additional release is > acceptable, Iwill update the release calendar to reflect the > followingchanges:* LTS 4.9.0.0_1.0* Development/Testing: 1 week > after 4.9.0.0release* RC Voting: 2 weeks after 4.9.0.0 release* > LTS4.9.0.0_2.0* Development/Testing: From 3 to 9 weeks of > the4.9.0.0 release* RC Voting: 10th week after the 4.9.0 releaseI > amfine with 4.9.0 as a LTS.But why a new vote for 4.9.0.0 as a > LTS? Isn't that a bitredundant?When we say 4.9.0 is good, what > doesn't make it good for a LTS?WidoI apologize for the relative > dates — we are still waiting for4.9.0.0 to complete > voting.Thanks,-johnjohn.burw...@shapeblue.com ( > -johnjohn.burw...@shapeblue.com ) (john.burw...@shapeblue.com ( > john.burw...@shapeblue.com > ))www.shapeblue.com<http://www.shapeblue.com ( http://www.shapeblue.com< > http://www.shapeblue.com ) ( http://www.shapeblue.com<http: > //www.shapeblue.com ( > http://www.shapeblue.com<http://www.shapeblue.com ) )>53 > ChandosPlace, Covent Garden, London VA WC2N 4HSUK@shapeblue > john.burw...@shapeblue.com ( john.burw...@shapeblue.com > ) ( john.burw...@shapeblue.com ( john.burw...@shapeblue.com > )) www.shapeblue.com ( http://www.shapeblue.com ) ( > http://www.shapeblue.com ( http://www.shapeblue.com ) )53 > Chandos Place,Covent Garden, London VA WC2N 4HSUK@shapeblue
