Hi, Am 02.02.2016 um 18:11 schrieb Emmanuel Bourg: > Hi all, > > Jenkins is going to be removed, this is the last dependency on the > groovy package. This opens the question of the groovy and groovy2 > packages. Should we: > > 1. Remove groovy and keep only groovy2. We may later reuse groovy for an > upcoming version 3.0. > > 2. Reuse groovy to package the next version of Groovy 2.x and then > remove groovy2 (we keep the 2.x artifact to avoid updating all the > reverse dependencies) > > 3. Turn groovy into a dummy package depending on groovy2. The groovy > package would become the equivalent of default-jdk, always pointing to > the latest version available. > > 4. Same as 3, but move groovy to src:groovy2 and remove src:groovy > > 5. Rename src:groovy2 into src:groovy and produce two packages groovy > and groovy2 (with groovy depending on groovy2). > > What do you think? I like having one source package src:groovy that always provides the latest upstream release and all its reverse-dependencies shall always work flawlessly with it. Amen. :-) We should try to avoid keeping packages around just because they may be useful later. Better keep packages as long as they are needed and reintroduce new packages when there is demand for it, e.g. to ease a transition. So I would prefer to package the next version of groovy 2.x in src:groovy and to remove src:groovy2. I can see the benefits of option number three but it should be limited to packages where we also provide an alternative like switching between two different JDKs and when many, if not all Java packages, are affected by this choice. So for me it's option 2 but don't we have to switch the r-deps in debian/control from groovy2 back to groovy again? Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature