I'm a very strong believer that CloudStack releases should always be upgradable from previous releases. We can't strand our user base on a previous release.
--Alex > -----Original Message----- > From: Wei ZHOU [mailto:ustcweiz...@gmail.com] > Sent: Wednesday, May 15, 2013 8:28 AM > To: dev@cloudstack.apache.org > Subject: Re: [ACS41] Discuss CLOUDSTACK-2463 being resolved in 4.1 vs 4.2 > > Half of our platforms are on 2.2.14 (advanced zone with security groups). > These platform work well. We are looking for a way to upgrade to 4.* for > more functionalities, so that we do not need to take the difference of > cloudstack version into account in development. > > As I know, the citrix guys are working on this. Jessica Wang said the feature > will be merged into master branch soon.It looks the coding is almost done. > > I hope this feature could be included in 4.1, of course. However, we also > need some days for testing and bug fix. It means cloudstack 4.1 will delay for > uncertain days (it is very bad, right?). It is a difficult choice. > > I do not know how many companies are using 2.2.14 (advanced zone with > security groups) and eager to upgrade. I will join the dev and testing if > needed. > > > 2013/5/15 Chip Childers <chip.child...@sungard.com> > > > Sebastian re-opened CLOUDSTACK-2463 due to users wanting to upgrade > > from 2.x to 4.1. This relates to the security groups feature being > > available when using VLANs in an advanced networking zone. This > > feature was apparently broken in the 3.x series, and is not slated to > > be reintroduced until 4.2. > > > > This is a horrible situation, and one that we've now encountered for a > > third time. > > > > IMO, we have 2 very specific options: > > > > 1) We pull that new feature into 4.1, and do the relevant testing. > > > > 2) We do not pull that feature into 4.1, and release as is with a > > strong message in the release notes highlighting that we know that 2.x > > to 4.1 will not support it (and state that those users requiring the > > feature should wait for 4.2). > > > > At this point, I don't have a preference. We probably need to > > understand the effort for (1), as well as understand who would do that > > work (dev AND testing). > > > > Thoughts? > > > > -chip > >
