On Wed, Mar 28, 2012 at 20:03, Vincent Massol <[email protected]> wrote:
> > On Mar 28, 2012, at 7:10 PM, Denis Gervalle wrote: > > > On Wed, Mar 28, 2012 at 12:27, Vincent Massol <[email protected]> > wrote: > > > >> Hi devs, > >> > >> I'd like to change our deprecation strategy. Here's what we are > currently > >> supposed to use (we voted it a long time ago): > >> > >> > http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HDeprecation26LegacyStrategy > >> > >> " > >> In addition our rule is to keep @deprecated methods/classes for 2 final > >> releases after the version where they were first added has been > released as > >> final. > >> For example if a method is deprecated in, say XE 1.3M2 then the method > >> will be removed in 1.6M1 or after. Of course any major new release can > >> deprecate anything. For example a XWiki 2.0 release is allowed to break > >> backward compatibility (obviously we need to be careful to offer a > >> migration path for users of previous major versions). > >> " > >> > >> Issues: > >> * This seems a bit harsh to me for some of our users/devs in the > community. > >> * We're not following which proves to me it's not a good rule > >> * It doesn't say anything about Scripting APIs which require a greater > >> stability in order not to break all wiki pages > >> > >> Definition of a Scripting API: > >> * a Script Service (that's the new way of providing script apis) > >> * a class in the "api" package in xwiki-platform-oldcore (this is the > old > >> way of providing script apis) > >> > >> Thus I'd like to propose this new rule: > >> > >> * Deprecated methods can only be removed in the next Release Cycle. For > >> example something deprecated in version N.x can be removed in version > N+1.y > >> where x and y can be anything. This is logical since N+1 means a new > major > >> release and it's common to understand that major releases have no > guarantee > >> of API compatibility (See > http://en.wikipedia.org/wiki/Software_versioningfor example). > >> * For scripting APIs we can remove deprecated API only after 4 Release > >> Cycles. For example since we're in 4.x this means we > > > > > > Why four ? isn't it too much ? > > The reason I proposed 4 is because nowadays there still are quite a few > XWiki 1.x instances in the wild so if people have coded apps on 1.x and > then upgrade to 4.0 (for ex) it would be nice if their app still works. > However I think it's ok to not support apis done in 0.9. And next year it > would be ok to drop 1.x api support, etc. > > It's long but then we can see in the wild that it's important we provide > stable scripting apis for users since they're used a lot while java apis > are used by more savvy user (developers) and thus having a shorter removing > cycle for them (1 year) should be ok. > > What would you like to propose instead? > At the same time, many feature as probably evolved since 1.x and may still render your application not workable AS IS in 4.x. Think about the skin, even if theorically albatross should still work, I am sure there is many unexpected issue with it, and using it in 4.x would probably not give you much advantage over your 1.x setup... My last experience between 3.1 and 3.4 has already issues. I would understand keeping compatibility so long if you do not introduce alternative, but in most case we do. I do not imagine a user of 1.x that really expect moving to 4.x without some effort, and without expecting some improvement other than a better core system. So, are we really targeting real use case ? Keeping compatibility is a huge effort in maintenance and may also slow down evolution, and I just found having a so long compatibility field, to be too much compare to our team. Also, having different policies for java and scripting is also a complexity, both in term of development and understanding. So I would be in favor to have a single policy for all. What Thomas propose seems really reasonable IMO, deprecating preferably in N+2.0. This is not a obligation anyway, and on a case by case basis we may still derogate to the rules, if a specific feature seems important to keep. There is no obligation for user to migrate, and with a clear deprecation documentation in the release notes, it should be quite easy to maintain old scripts. WDYT ? > > Thanks > -Vincent > > >> can remove deprecated APIs from 0.x releases. And when we start 5.x we > >> will be able to remove deprecated scripting apis deprecated in 1.x. > >> > >> Here's my +1 > >> > >> Thanks > >> -Vincent > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
