Trying to go back to action: any objection to release master as it (ie with asm7 module and a dropped asm6 module)? Sounds like the best compromise we can get - and the same as commons.
Side note: if we need we can create a maintenance branch for asm6 but from experience we always moved forward - cause java support way ;) - and never needed to go back so sounds good enough to move forward to keep trunk as it. If no objection I will try to launch it hopefully tomorrow or later this week. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 2 oct. 2018 à 09:21, Romain Manni-Bucau <[email protected]> a écrit : > > > > > Le mar. 2 oct. 2018 à 00:34, David Blevins <[email protected]> a > écrit : > >> > On Oct 1, 2018, at 7:12 AM, Romain Manni-Bucau <[email protected]> >> wrote: >> > >> > :) as usual with asm, looks ok but breaks several apps ;). But main >> point is: do we want to export as asm6 the real asm7 and fake the runtime >> it will work? If we want a smooth upgrade we can update asm6 module to have >> some of changes but keep asm7 module to ensure we cover it IMHO. >> >> We should definitely not introduce ASM 7 code into our asm6 module. >> >> Another topic is we've been on ASM 6 for 2 years. Should we change the >> XBean major version to 5 when we switch to ASM 7? >> > > Since some years I really think we should explode xbean to be able to have > this real versioning otherwise we are always between "this part needs a new > major but not this one for consistency". > > >> >> That would give us the option to keep pushing out XBean 4.x releases with >> further ASM 6 updates for those who can't/won't upgrade yet or also have >> stable branches to maintain. >> > > Strictly speaking we can have asm[3-7] in the same source tree so not sure > it helps to move in one direction or the other. > > >> >> If if we don't change the major version and any critical bugs or security >> vulnerabilities hit XBean 4.10, we'd have to do a 4.10.1. If that happened >> a few times we'd find ourselves with 4.10.2, 4.10.3 and effectively >> maintaining a de facto branch, just after the fact and in a very awkward >> way. >> > > I actually like that for multiple reasons: > > 1. upgrading is a very doable work for all projects which would require > such an upgrade so not a blocker > 2. we can always lazily create a maintenance branch from a tag (vs eagerly > which is generally useless) and when done it does not get more love than > the CVE fix if it exists > > At the end it is the less costly solution IMHO. > > >> >> >> -David >> >>
