I have no problem with changing the artifactId to Foo2 and the packages to match and then starting at 1.0. I’d also be OK with increasing the version number. If the API really is incompatible IMO changing the artifactId is the best indicator of that.
Ralph > On Jun 7, 2016, at 11:47 AM, Matt Sicker <boa...@gmail.com> wrote: > > What version number would you use to indicate that the API barely matches > anymore then? Different group or artifact IDs? > > On 7 June 2016 at 12:12, Ralph Goers <ralph.go...@dslextreme.com> wrote: > >> Actually, a 6.0 release with the same coordinates would imply that there >> are behavioral changes but the API is sufficiently compatible that you >> won’t get things like NoSuchMethodError. >> >> Ralph >> >>> On Jun 7, 2016, at 9:33 AM, Andrey Loskutov <losku...@gmx.de> wrote: >>> >>> On Tuesday 07 June 2016 17:26 sebb wrote: >>>> On 7 June 2016 at 17:18, Andrey Loskutov <losku...@gmx.de> wrote: >>>>> On Tuesday 07 June 2016 17:15 sebb wrote: >>>>>> There have been quite a lot of changes to BCEL since 5.2. >>>>>> >>>>>> Lots of places currently mention 6.0 (@since; JIRA; probably >> elsewhere). >>>>>> >>>>>> So whilst 5.3 might be OK as the next release version, it's going to >>>>>> be a lot of work to change all the references. >>>>>> >>>>>> I therefore propose we should use 6.0 for the backwards compatible >>>>>> release using the original Java package names and Maven coordinates. >>>>>> >>>>>> A subsequent incompatible release can always use 7.0. >>>>> >>>>> +1 for 6.0. >>>>> Even if BCEL trunk code after some backwards compatible changes will >> don't break the BC, it most likely will break the behavior. >>>> >>>> Hopefully not, otherwise it negates most of the reasons for providing >>>> a compatible release. >>>> >>>> It may be acceptable to break behaviour in such a way that only a few >>>> unusual use cases are broken, but if every downstream user has to >>>> recode their app then there's no point in striving for BC. >>>> >>>> AIUI the whole point of the exercise is to provide a drop-in release. >>> >>> As I saw in FindBugs after experimental port to BCEL6 ( >> https://issues.apache.org/jira/browse/BCEL-273), one still need to care >> about behavior changes - it is a major release. >>> And this is acceptable for me as a user of that API, because I know that >> nothing is for free. >>> But the hope is that this can be handled with much smaller effort and >> without affecting / breaking other 3rd party libraries. >>> So in best case this is a drop-in, in *worst* case one need to fix some >> smaller issue here and there, but it is definitely not a nightmare of >> changing *everything*, entire software stack, just to be able to run on >> Java 7/8. >>> >>> -- >>> Kind regards, >>> google.com/+AndreyLoskutov >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
