I am glad this has led to some discussion. I do not take a strong position into how we solve the issue but want to make sure we deal with this old code in some way. In terms of justifying the work to my sponsor, I cannot (or do not want to) afford to clean all of it nor to investigate into the exact amount of users still on old versions.
The reason I choose this approach is practical: our present db scheme is the 4.0.0 scheme with upgrades applied on it. As it is the most practical/easiest I still stand by it, in full recognition of the documentation need of course. At present the opinions seem to be to diverse to get to concensus but I am sure that is only appearance. Talking of a 5.0 is there and it seems sensible but a long way. It makes sense to me to not stop improving the overall quality of the project untill then and this code is one item we should address. 5.0 is going to involve the API as well. ignoring defects on coverity would be fine safe that we should then also make sure the code is not run and specially not copy&pasted. just some extra oil to burn, Daan On Wed, Jul 22, 2015 at 11:55 AM, Boris Schrijver <bo...@pcextreme.nl> wrote: > +1 on dropping the pre-4.x upgrade code, if done in a documented manner. > Instead > of voting to drop it now shall we vote to drop it in a future release with > documentation and put it on the roadmap? Like: > > At release 4.6: Initial notice to drop pre-4.x upgrade code at release 5.0. > At release 4.6: Suppress pre-4.x upgrade code from coverity scan. > At release 5.0: Drop pre-4.x upgrade code entirely. > At release 5.0: Create documentation to show upgrade path from pre-4.x to 5.0. > > Best regards, > > Boris Schrijver > >> >> On July 22, 2015 at 11:42 AM Koushik Das <koushik....@citrix.com> wrote: >> >> >> -1 to dropping pre-4.x upgrade code. If possible we should suppress the >> old upgrade files from coverity scan. >> >> Reasons: >> There may be users on pre-4.x versions. >> Removing a functionality should be associated with proper documentation >> and an advanced notification in some prior releases. This is similar to the >> way some API is deprecated and then eventually removed. >> >> -Koushik >> >> -----Original Message----- >> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] >> Sent: Monday, 20 July 2015 17:19 >> To: dev >> Subject: [PROPOSAL] drop old upgrade code >> >> LS, >> >> In coverity the only remaining high impact issues are concerned with >> upgrade code. Some of it is in 4.3 and 4.5 code but most in pre-4 upgrades. >> >> I addressed the file Upgrade218to22.java in a PR [1] and I move that we >> don't pull it but instead drop the file altogether together with all upgrade >> code dating prior to 4.0.0. anybody on older versions can still upgrade to >> any >> version between 4.0 and 4.5 and move on from there. >> >> My objective is to have no high impact issues remaining so we clearly see >> when we are digressing beit by hand or in an automated way. >> >> +1? >> >> [1] https://github.com/apache/cloudstack/pull/603 >> -- >> Daan >> -- Daan
