On Fri, Nov 6, 2015 at 4:42 PM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Fri, 6 Nov 2015 17:02:01 -0700, Phil Steitz wrote: > >> On 11/6/15 4:46 PM, Gary Gregory wrote: >> >>> On Fri, Nov 6, 2015 at 3:01 PM, Phil Steitz <phil.ste...@gmail.com> >>> wrote: >>> >>> On 11/6/15 2:51 PM, Gary Gregory wrote: >>>> >>>>> On Fri, 6 Nov 2015 09:17:18 -0700, Phil Steitz wrote: >>>>>> >>>>>>> Here is an idea that might break our deadlock re backward >>>>>>>>>>> compatibility, versioning and RERO: >>>>>>>>>>> >>>>>>>>>>> Agree that odd numbered versions have stable APIs - basically >>>>>>>>>>> adhere >>>>>>>>>>> to Commons rules - no breaks within 3.0, 3.1, ..., 3.x... or 5.0, >>>>>>>>>>> 5.1... but even-numbered lines can include breaks - >>>>>>>>>>> >>>>>>>>>>> ... >>>>>>>>>> >>>>>>>>> This sounds awfully complicated for my puny human brain. >>>>> >>>> How, exactly? Seems pretty simple to me. The even-numbered release >>>> lines may have compat breaks; but the odd-numbered do not. >>>> >>>>> It's bad enough that I have to remember how each FOSS project treats >>>>> versions numbers, but having an exception within a Commons component is >>>>> even worse. This is a non-starter for me. >>>>> >>>> Do you have any better suggestions? The problem we are trying to >>>> solve is we can't RERO while sticking to the normal compat rules >>>> without turning major versions all the time, which forces users to >>>> repackage all the time and us to support more versions concurrently >>>> than we have bandwidth to do. >>>> >>>> I do not see how a different version scheme will determine how many >>> branches the community supports. >>> >> >> If we just keep one 4.x branch that keeps cutting (possibly >> incompatible) releases, that is just one line, one branch. If we >> have to cut 4.1, 4.2, 4.3 as 4, 5, 6 instead and we don't allow any >> compat breaks, we end up having to maintain and release 4.0.1, >> 5.0.1, 6.0.1 instead of just 4.3.1, for example, or we just strand >> the 4, 5 users in terms of bug fixes as we move on to 6. >> >>> >>> Breaking BC without a package and coord change is a no-go. >>> >> >> We have done this before and we will probably do it again - and more >> if we have to don't separate out an unstable line. >> >>> You have to >>> think about this jar as a dependency that can be deeply nested in a >>> software stack. Commons components are such creatures. I unfortunately >>> run >>> into this more than I'd like: Big FOSS project A depends on B which >>> depends >>> on C. Then I want to integrate with Project X which depends on Y which >>> depends on different versions of B and C. Welcome to jar hell if B and C >>> are not compatible. If B and C follow the rule of break-BC -> new >>> package/coords, then all is well. >>> >> >> The mitigation here is that we would not expect the even-numbered >> releases to be deployed widely. >> > > Or we can prevent any potential JAR hell by changing the top-level > package name for every release in the unstable series: > > 4.0 -> org.apache.commons.math4u0 > 4.1 -> org.apache.commons.math4u1 > > This would also offer the possibility to write a code using > classes from several unstable releases (e.g. to compare their > performance). Pardon my daftness, but if you change package/coord names, what are you gaining compared to the usual major version changes? Gary > > Gilles > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
