No argument there! My only point was that perhaps in scala a slightly
different policy might make sense. Because certain features of scala are
more backwards-compatable then others, and you are still forced to recompile
your libraries/projects to all use the same scala version, I think whatever
version system you use should focus on the following aspects:
- Binary Comptability Issues
- Internal changes on classes or object methods, no API changes. No
need to recompile project
- Minor API changes (additions of methods, internal method
implementation changes not belonging to traits.). No Need to recompile
project
- Minor Trait implementation and API changes. Requires a recompile of
anything extending from these traits. Binary incompatable as of
how traits
compile today. Source should still remain compatible.
- Major changes -> similar to above, requires rebuild of project.
- Source Compatability Issues
- A project on previous version could be compiled against current version
but with potential deprecation warnings
- This could even include method signature changes if, e.g. an
implicit conversion from one type of argument to the new argument is
provided. I beleive is this implicit is @deprecated, then it
will issue a
warning on conversion. I know Mark Harrah uses this to acheive
source-compatability across the SBT scalac plugin.
- A project on the previous version could not be compiled against this
version, re-writing code is required.
My opinion on a version system for scala is as follows (unfortunately 2.8.0
breaks some of these rules...)
X -> This X version implies source-incompatible changes from previous X
versions
X.Y -> The Y version implies source-compatible, but binary incompatible
changes from previous X versions.
X.Y.Z -> The Z version implies internal changes such that only
classes/objects extending traits need to be recompiled.
X.Y.Z.A -> The A Version implies a completely internal change such that no
recompilation is necessary (I don't see these happening all that often in
real life.. Traits are far to useful!).
This adds an additional layer from the normal OSGi versioning system. My
reasoning is that we hope X.Y.Z.A version numbers disappear (in favor of
X.Y.Z) as research into how to compile traits for the JVM improves.
Notice as well that X.Y is only *source* compatible. Not
binary-compatible. That's the other difference from an OSGi perspective.
The real question is, with all these breaking changes in lift 1.1, has any
attempt been made at source-compatability? If not, I would argue a bigger
version jump than 1.1.
Also, there is the possibility of taking the version system and adding a
"functionality milestone" version at the begginning. In this case, you can
use that number for marketting purposes (e.g. "Lift goes 1.0!). Your
version number would then be <Marketing>.<SourceCompatability>.<All but
Trait BinaryCompatability>.<Binary Compatibility>.
In this case, perhaps a "1.1" release makes sense vs. a "1.0" release.
The question is, should it have been 1.0.2 or 1.0.0.2?
Anyway, those are my thoughts, let me know what you think.
- Josh
On Sun, Nov 22, 2009 at 4:33 AM, Heiko Seeberger <
[email protected]> wrote:
> 2009/11/21 Josh Suereth <[email protected]>
>
> I think eclipse and maven might be two of the only projects following that
>> convention (besides others in the eclipse ecosystem).
>
>
> I think that Spring also follows the recommended OSGi versioning policy,
> but to be sure I will check with some of the Spring folks. And what about
> Java EE? Just remember 2.0->2.1 (small refinements and additions) and then
> 3.0 (very very breaking stuff).
>
>
>> The question in my mind is what is the popular version number convention
>> in the Scala ecosystem.
>
>
> As far as I can tell, e.g. from the 2.8 or 3.0 discussion on
> scala-internals, not many folks from Scala world are interested or trustful
> in versioning policies. So why not make Lift the thought leader in this
> regard?
>
> Heiko
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<liftweb%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=.
>
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=.
