Use-cases for version ranges?

cowwoc cowwoc at bbs.darktech.org
Mon Nov 21 11:36:20 PST 2011 

     One way I could see this working is replacing version ranges with a 
list of specific versions. Since OSGI's versioning scheme is fixed, 
expanding the range into specific version numbers is easy to do.

     To touch upon Brian's point, not only do version ranges come with 
extra conceptual weight, but they also force us to fix the versioning 
scheme (which I'm strongly against), or introduce a Comparator, or... 
The point is, they come at a cost. I'm still of the opinion that you 
cannot certify compatibility on a range of versions, rather you must 
specify a list of *individual* versions which the author has tested one 
by one. Version ranges imply (to me at least) that someone made a guess.

Gili

On 21/11/2011 1:18 PM, Brian Pontarelli [via jigsaw-dev] wrote:
> This is something I had forgotten about because I haven't used OSGi in 
> quite a while. I'll need to consider it more, but my initial thought 
> is that these might not co-exist well. Although, perhaps there is a 
> way to translate OSGi version ranges to a compatibility verification 
> system under JMS (or any other system that uses compatibility 
> verification as I've defined it).
>
> Thanks for reminding me about OSGi's version system. I'll definitely 
> have to go back and think about it some more.
>
> -bp
>
>
> On Nov 21, 2011, at 10:50 AM, Neil Bartlett wrote:
>
> > Brian,
> >
> > In that case it seems you're prepared to sacrifice a large body of 
> existing code, i.e. the OSGi bundles that use version ranges already. 
> That doesn't seem very consistent.
> >
> > I'm all for pragmatism. Version ranges can always be locked down to 
> a single point if you desire, but you cannot unlock a point-version 
> system and turn it into one with ranges.
> >
> > I also understand that adding excessive features carries conceptual 
> weight that can make a system harder to use. Conversely omitting 
> features that are needed makes it *much* harder to use. Version ranges 
> fall into the latter category because they are actually used in 
> practice, and you're proposing to take them away from everybody just 
> because some people don't want to use them.
> >
> > Regards
> > Neil
> >
> >
> > On Monday, 21 November 2011 at 17:37, Brian Pontarelli wrote:
> >
> >> To answer your "well so what??" question, adding a feature simply 
> to have a feature seems really dangerous to me. I'd much rather be 
> pragmatic about what needs to be included to support the current code 
> written in Java and what needs to be included to allow a module system 
> to work.
> >>
> >> I don't see version ranges and certain other items being necessary 
> features. I also see some features as adding pain points rather than 
> alleviating them.
> >>
> >> -bp
> >>
> >>
> >> On Nov 21, 2011, at 9:11 AM, Neil Bartlett wrote:
> >>
> >>> David,
> >>> I'm likewise tired of hearing these defeatist straw-man arguments.
> >>> First, nobody is suggesting that you be forced to use version ranges.
> >>> Second, nobody is suggesting that you be forced to design software by
> >>> separating interfaces from implementation. Finally, nobody is
> >>> suggesting that unmodified legacy code can be trivially 
> modularised in
> >>> *any* module system.
> >>> The module system must support both existing software and new
> >>> software, of course. You seem suggest that I believe existing 
> software
> >>> is unimportant; nothing could be further from the truth. But I also
> >>> believe that new software is important and that practices like
> >>> interface/implementation separation and semantic versioning will help
> >>> make the new software better than the old software.
> >>> Therefore I believe that these features must be supported (though not
> >>> mandated) in any new module system. You appear to be suggesting that
> >>> these features are worthless because they cannot be applied to
> >>> existing software, and/or will not be used by all Java developers.
> >>> Well so what??
> >>> Regards,Neil
> >>> On Mon, Nov 21, 2011 at 3:15 PM, David M. Lloyd <[hidden email] 
> </user/SendEmail.jtp?type=node&node=5011266&i=0>> wrote:
> >>>> I'm tired of hearing pie-in-the sky, "intro to OOP" wishful crap 
> like this.
> >>>> Mission one should be supporting *existing* code. The fact is 
> that people
> >>>> do *not* always split their API from their implementation, and 
> APIs almost
> >>>> *never* consist solely of interfaces. There are many ways of 
> designing an
> >>>> API which people consider "right" and I don't see anyone on this 
> list having
> >>>> any special insight that would enable them to select the "one 
> true" approach
> >>>> to API design.
> >>>>
> >>>> The fact is that any version scheme or module resolution engine 
> which only
> >>>> works for new code which is designed "properly" for it is *going* 
> to fail.
> >>>> And there's no reason for such constraints anyway. Version ranges 
> are
> >>>> barely useful at all in practice. The only ones who can assert
> >>>> compatibility between two libraries of arbitrary version are the 
> ones who
> >>>> have tested the two together (along with anything else that uses a
> >>>> combination of the two).
> >>>>
> >>>> The best one can do establish *minimum* compatibility based on 
> available
> >>>> features, and test test test. When a module is added to a 
> repository, if it
> >>>> is tested by running both its internal unit tests and all 
> available tests of
> >>>> all its dependents, then that should be adequate to establish 
> compatibility
> >>>> *within a repository*. There are too many factors to establish
> >>>> compatibility beyond it.
> >>>>
> >>>> On 11/20/2011 07:45 AM, Neil Bartlett wrote:
> >>>>>
> >>>>> Stephen,
> >>>>>
> >>>>> You again seem to be talking about dependencies on implementation
> >>>>> packages. If we depend on APIs consisting primarily of interfaces,
> >>>>> then versions and version ranges are reliable and can be completely
> >>>>> automated.
> >>>>>
> >>>>> Regards,
> >>>>> Neil
> >>>>>
> >>>>>
> >>>>> On Sun, Nov 20, 2011 at 12:25 PM, Stephen McConnell<[hidden 
> email] </user/SendEmail.jtp?type=node&node=5011266&i=1>>
> >>>>> wrote:
> >>>>>>
> >>>>>> I could say that the question is academic - but here is the 
> thing - its
> >>>>>> not
> >>>>>> even academic.
> >>>>>>
> >>>>>> We talk about versions and yet the platform has no computational
> >>>>>> mechanisms
> >>>>>> to flag version violation. At least an academic discussion 
> would bring in
> >>>>>> grounded metrics. In reality - the discussion here about V1 
> versus V2
> >>>>>> and
> >>>>>> that warm fuzzy feeling when your are just a n.m from an n+1 
> and it's a
> >>>>>> waste of breath (and that comment goes to all sides of the 
> debate).
> >>>>>>
> >>>>>> Give me an endorsed tool that shows me that module 
> [name]-[build] is
> >>>>>> computationally backward compatible to a different 
> [name]-[build] and
> >>>>>> then,
> >>>>>> only them will this discussion have reasonable grounds to 
> assert any
> >>>>>> authority on the subject of version compatibility (past or 
> future).
> >>>>>> Without
> >>>>>> that tool - versioning is a unqualified statement of trust. And 
> the
> >>>>>> evidence
> >>>>>> suggests that the threshold of trust delivery on actual 
> computational
> >>>>>> compliance is really really thin.
> >>>>>>
> >>>>>> Cheers, Steve.
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message----- From: cowwoc
> >>>>>> Sent: Sunday, November 20, 2011 1:39 PM
> >>>>>> To: [hidden email] 
> </user/SendEmail.jtp?type=node&node=5011266&i=2>
> >>>>>> Subject: Re: Use-cases for version ranges?
> >>>>>>
> >>>>>>
> >>>>>> I'd like to propose another possibility: the author of the
> >>>>>> dependency should tell *us* about version compatibility, not 
> the other
> >>>>>> way around. For example:
> >>>>>>
> >>>>>> 1. The author of module A declares a dependency on module B 
> version 1.2
> >>>>>> (specific version).
> >>>>>> 2. The author of module B publishes version 1.3. He declares that
> >>>>>> version 1.3 is compatible with 1.2 (meaning, the runtime system is
> >>>>>> allows to substitute version 1.3 for 1.2).
> >>>>>>
> >>>>>> The upside of this approach is that the author of B is in a better
> >>>>>> position to declare compatibility than the author of A. The 
> author of A
> >>>>>> still only needs to test a single version. What do you think?
> >>>>>>
> >>>>>> Gili
> >>>>>>
> >>>>>> On 19/11/2011 1:59 AM, Neil Bartlett wrote:
> >>>>>>>
> >>>>>>> Gili,
> >>>>>>>
> >>>>>>> I didn't say anything about guarantees, and in this industry I 
> have
> >>>>>>> never heard of anybody providing a guarantees about the 
> performance of
> >>>>>>> their software, especially in the presence of external 
> dependencies.
> >>>>>>>
> >>>>>>> Version ranges are a means of communicating expectations, and we
> >>>>>>> provide both a lower and an upper bound because this is useful
> >>>>>>> information. I expect my module will work with 1.2.14, and I 
> expect it
> >>>>>>> will not work with 2.0. If I were a provider of the API rather 
> than a
> >>>>>>> consumer then I would have a much narrower expectation, e.g.
> >>>>>>> [1.2,1.3), and this would also be useful information to convey.
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> Neil
> >>>>>>>
> >>>>>>> On Sat, Nov 19, 2011 at 4:27 AM, cowwoc<[hidden email] 
> </user/SendEmail.jtp?type=node&node=5011266&i=3>>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Neil,
> >>>>>>>>
> >>>>>>>> I guess I don't understand why Jigsaw should work differently 
> from
> >>>>>>>> Maven
> >>>>>>>> on this point. I am expecting developers to specify specific 
> versions
> >>>>>>>> that
> >>>>>>>> they tested (point versions, not ranges) and end-users may 
> override
> >>>>>>>> these
> >>>>>>>> "recommendations" as they see fit.
> >>>>>>>>
> >>>>>>>> Where you see version range [1.2.14, 2.0) as a way of 
> communicating
> >>>>>>>> "the
> >>>>>>>> developer guarantees 1.2.14 but you may use newer versions up 
> to 2.0 at
> >>>>>>>> your
> >>>>>>>> own risk" I'd expect the developer to simply specify 1.2.14 
> and there
> >>>>>>>> should
> >>>>>>>> be no limit on what version end-users may use if they so wish.
> >>>>>>>>
> >>>>>>>> Gili
> >>>>>>>>
> >>>>>>>> On 18/11/2011 2:23 AM, Neil Bartlett wrote:
> >>>>>>>>>
> >>>>>>>>> I noticed that I failed to address your point about Maven 
> using point
> >>>>>>>>> versions.
> >>>>>>>>>
> >>>>>>>>> Maven is a build tool. At build time we need to compile 
> against a
> >>>>>>>>> single specific version so that we have repeatable builds. 
> In general
> >>>>>>>>> we should build each module against the lowest version of 
> the library
> >>>>>>>>> that it can possibly use, and there are no major negative 
> consequences
> >>>>>>>>> of having several versions of a library at build time 
> (except that
> >>>>>>>>> Maven has to download a lot!). At runtime however we need to 
> have the
> >>>>>>>>> flexibility to substitute a single compatible version.
> >>>>>>>>>
> >>>>>>>>> Neil
> >>>>>>>>>
> >>>>>>>>> On Fri, Nov 18, 2011 at 7:10 AM, Neil Bartlett<[hidden 
> email] </user/SendEmail.jtp?type=node&node=5011266&i=4>>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Suppose as the developer of module A, I declare a 
> dependency on
> >>>>>>>>>> log4j,
> >>>>>>>>>> exactly version 1.0.0 because I have not tested against 
> log4j 1.0.1,
> >>>>>>>>>> 1.0.2, 1.3, 999.999 etc. I effectively prevent my module 
> *ever* being
> >>>>>>>>>> used with log4j version 1.0.1 even if this combinations is 
> later
> >>>>>>>>>> tested and proven to work by somebody else. In other words, 
> testing
> >>>>>>>>>> is
> >>>>>>>>>> important but it doesn't necessarily have to always be done 
> by the
> >>>>>>>>>> original developer of each module.
> >>>>>>>>>>
> >>>>>>>>>> On the other hand let's say I state my dependency using the 
> following
> >>>>>>>>>> range: [1.2.14, 2.0). This is OSGi syntax and I believe 
> Jigsaw is
> >>>>>>>>>> following it, and it simply means I accept version 1.2.14 
> up to but
> >>>>>>>>>> not including 2.0. Anybody can see that I compiled and 
> tested against
> >>>>>>>>>> 1.2.14, but has the option of using 1.2.15, 1.2.16, 1.3, 
> 1.9 etc. It
> >>>>>>>>>> does not mean that I *guarantee* my module will work with 
> log4j 1.3
> >>>>>>>>>> because that obviously depends on whether the log4j authors 
> accept
> >>>>>>>>>> and
> >>>>>>>>>> follow the common semantics of indicating 
> backwards-incompatible
> >>>>>>>>>> changes with a bump to the first version segment.
> >>>>>>>>>>
> >>>>>>>>>> The consequence of trying to lock down imports to a narrow 
> range or
> >>>>>>>>>> even a point version is that assembling an application 
> becomes very
> >>>>>>>>>> difficult, and we are forced to deploy many versions of common
> >>>>>>>>>> libraries concurrently. This is non-optimal, though we can 
> handle it
> >>>>>>>>>> to some degree via per-module classloaders as in OSGi.
> >>>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>> Neil
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Nov 17, 2011 at 11:52 PM, cowwoc<[hidden email] 
> </user/SendEmail.jtp?type=node&node=5011266&i=5>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Can someone please explain why modules need to be able to 
> specify
> >>>>>>>>>>> version
> >>>>>>>>>>> ranges for dependencies? I believe OSGI allows the 
> specification of
> >>>>>>>>>>> version
> >>>>>>>>>>> ranges while Maven allows the specification of individual 
> versions.
> >>>>>>>>>>>
> >>>>>>>>>>> The only thing that comes to mind is when module C depends 
> on A and
> >>>>>>>>>>> B,
> >>>>>>>>>>> A
> >>>>>>>>>>> depends on log4j 1.0, and B depends on log4j 1.1. What 
> does C do? Is
> >>>>>>>>>>> this
> >>>>>>>>>>> the main use-case for version ranges?
> >>>>>>>>>>>
> >>>>>>>>>>> By the sound of it, this is a trust model where developers 
> are told
> >>>>>>>>>>> that
> >>>>>>>>>>> log4j 1.x won't break compatibility so they depend on that 
> range
> >>>>>>>>>>> without
> >>>>>>>>>>> actually testing against each version (newer versions may be
> >>>>>>>>>>> released
> >>>>>>>>>>> after
> >>>>>>>>>>> their own software). I question whether such a mechanism 
> is better
> >>>>>>>>>>> or
> >>>>>>>>>>> worse
> >>>>>>>>>>> than depending on individual versions which may be 
> overridden at a
> >>>>>>>>>>> later
> >>>>>>>>>>> time (a la Maven). On the one hand, you don't need to 
> release a new
> >>>>>>>>>>> version
> >>>>>>>>>>> of the application each time a dependency is updated. On 
> the other
> >>>>>>>>>>> hand,
> >>>>>>>>>>> no
> >>>>>>>>>>> one is actually running tests to ensure that the versions 
> are really
> >>>>>>>>>>> compatible.
> >>>>>>>>>>>
> >>>>>>>>>>> Is there a way to get module A to see log4j 1.0 and module 
> B to see
> >>>>>>>>>>> log4j
> >>>>>>>>>>> 1.1 (using separate ClassLoaders)?
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>> Gili
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> View this message in context:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 
> http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5002801.html
> >>>>>>>>>>> Sent from the jigsaw-dev mailing list archive at Nabble.com.
> >>>>
> >>>>
> >>>> --
> >>>> - DML
> >
>
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the 
> discussion below:
> http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5011266.html 
>
> To unsubscribe from Use-cases for version ranges?, click here 
> <http://jigsaw-dev.1059479.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5002801&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTAwMjgwMXwxNTc0MzIxMjQ3>.
> NAML 
> <http://jigsaw-dev.1059479.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> 
>



--
View this message in context: http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5011446.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.

More information about the jigsaw-dev mailing list