cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: Do not retroactively change upgrade files....
Date Thu, 20 Dec 2012 03:11:37 GMT
Didn't know you can do that.  Do we have enough control on apache git repo to do this?

--Alex

> -----Original Message-----
> From: Anthony Xu [mailto:Xuefei.Xu@citrix.com]
> Sent: Wednesday, December 19, 2012 5:24 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: Do not retroactively change upgrade files....
> 
> Since we have upgrade java/script for each release, can we make upgrade
> java/script read only in GIT after release?
> 
> Anthony
> 
> > -----Original Message-----
> > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> > Sent: Wednesday, December 19, 2012 4:49 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Do not retroactively change upgrade files....
> >
> > I ran into a case where someone has gone back to an database upgrade
> > and retroactive changed that upgrade after the release went out.   That
> > is a big no-no.  Once the release went out, the database upgrade file
> > is established.  Any bug introduced or didn't deal with by that upgrade,
> > you better be dealing with it in the next release's upgrade.
> >
> > For example,
> >
> > From 3.0.2 to 4.0.0, we forgot to upgrade something.  So in the 4.0.1
> > release, we retroactively change the 3.0.2 to 4.0.0 upgrade to add that.
> > Sure it looks like the right thing to do.  If they were upgrading from
> > 3.0.2 to 4.0.1, everything works great.  However, if the user upgrades
> > from 3.0.2 to 4.0.0 and then from 4.0.0 to 4.0.1 will miss the upgrade.
> > This is the simplest example.  There are much more complicated examples
> > that you have to deal with.
> >
> > There is no changing upgrade files retroactively.  Deal with it in the
> > new release.
> >
> > --Alex
> >


Mime
View raw message