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 policies and CI…? > On Jan 12, 2016, at 1:11 AM, ilya <ilya.mailing.li...@gmail.com> wrote: > > Hi Rene > > > In short BIG +1, for longer summary, please read below.... > > > PS: For LTS - you mean "Long Term Support" i assume. > > We would be interested in seeing the support of 4.5 longer as well, as > we are happy with what we got so far and dont have a burning need to > upgrade yet. > > Upgrade would also require serious testing across the board, so LTS > release can buy us more time. > > This is my opinion, Marcus would probably have a different opinion on this. > > --------- > > Side note: > I had a somewhat similar endeavor few years back that attempted to solve > this challenge. Though it was not just around "Long Term Support", but > geared more towards "I need latest bug fix and feature now, I dont have > 8+ months to wait". > > I called the project CloudSand. > > Back then, i was mostly focusing on ACS + VMware Integration, as the > code existed in master branch but not in 4.1. Also did a small talk > about it back in 2013 @ CCC in SF Bay area. > > https://www.youtube.com/watch?v=4wuEPoxVlBM > > You can see it under www.cloudsand.com - though now no longer > maintained due to $dayjob$ restrictions (its complicated). > > Either way, i'm in strong support of this initiative. I'm thinking just > about anyone with fairly sized infrastructure - might do the same, why > not merge the efforts? > > Things to consider (this is strictly my opinion): > 1) Pull/merge requests must be reviewed with scrutiny, we dont want LTS > to be a test bed, but rather a stable build > 2) Database changes should be avoided unless someone wants to maintain > upgrade path, i just think it would be easier to just not pull commits > that require DB change > 3) End user should be able to upgrade to latest official ACS version > without any issues or switch between - there should be no lock in.. > > I'd like to help with this effort, but don't know how much time i can > dedicate to this effort. > > Regards, > ilya > > > > On 1/9/16 2: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 (which one to take? Are fixes backported? How long will it >> receive fixes? Do I have to upgrade?). >> >> We leads me to the question: Does CloudStack need an LTS version? To me >> it would make sense in many ways: >> >> * Users in restrictive cloud environments can choose LTS for getting >> backwards compatible bug fixes only. >> >> * Users in agile cloud environments can choose latest stable and getting >> new features fast. >> >> * CloudStack developers must only maintain the latest stable (mainline) >> and the LTS version. >> >> * CloudStack developers and mainline users can accept, that mainline may >> break environments but will receive fast forward fixes. >> >> To me this would make a lot of sense. I am actually thinking about >> maintaining 4.5 as a LTS by myself. >> >> Any thoughts? +1/-1? >> >> Regards >> René >>
