Hi all!

Avi Bryant <avi at beta4.com> wrote:
> On Wed, 23 Oct 2002 goran.hultgren at bluefish.se wrote:
> 
> > If I didn't introduce that term it means more or less that if a package
> > A is dependent on version 1.22 of B then if B moves to 1.25 by 3 update
> > ChangeSets all classified as "no behaviour change" then we can be sure
> > that A will work with B 1.25 too. And if say the last one is classified
> > as "should be backwards compatible" we can still be pretty safe, etc.
> > So, the dependency can "stretch".
> 
> Can't this be done more simply by using a major.minor.patch convention for
> version numbers?  You could have a dependency on 1.2, which would accept
> 1.2.0, 1.2.2, 1.2.5, etc...

Yes, true it can. 

Backtracking: My thinking started with making ChangeSets smarter and
better, and then I thought that a new "beast" would be simpler to
implement than hacking in ChangeSet and I started thinking in terms of
Patch (a new class similar to ChangeSet with these capabilities) and
then someone said "Simpler!" and then I said that ok, we can use
ChangeSets if we classify them manually instead (some of this can be
automated of course). And finally if we make it even simpler we can drop
the idea of classifying the updates and just classify "released" package
versions. And finally we can drop the idea of using classifications at
all and instead rely on a numbering scheme that we *all agree on*. He,
that last part might get funny.

Anyway, the idea of classifying the updates one by one would allow a
cumulative aspect which is nice. Let me insert something from an email
with Daniel:
----
> Patches could be "graded" like:
> 1. Guaranteed behavior preserving. (only class comments, method
> comments, method formatting, category changes - we could even compare
> bytecodes of methods before and after to make sure!)
> 2. Behavior extensions. (the developer has added behavior as for example
> added methods/classes but hasn't changed existing methods)
These two are definitely computable, and definitely as computable from
differences as from stored sequences. They definitely help - if software
promises that version is definitely compatible, you (the integrator)
will simply not do (as much) testing, and focus on understanding the
additions/naming mods.

> 3. Likely to be behavior preserving. (the developer has done changes but
> *think* they don't affect behavior)
> 4. Compatible. (the developer has done changes to existing code that
> does indeed change behavior but should still be compatible)
> 5. Likely non compatible. (the developer has changed protocols and think
> that at least some packages will be affected)
> 6. Non compatible. (the developer is sure that dependent packages are
> non compatible)
These aren't computable, and as an Integrator, I wouldn't change my
behavior much based on seeing them proclaimed. Maybe an SM category on
an update would convey this fairly enough.
 
> In fact - we could even start using the above classification of
> ChangeSets and then use that as "Patch" to begin with. As you realize
> this will mean that packages/users will have better control - if
> SqueakMap says to you "You are installing package X which is dependent
> on Comanche 4.12 but you have packages depending on the installed
> Comanche 5.0. Comanche 5.0 is classified as a "compatible" with Comanche
> 4.12 - would you like to proceed?" wouldn't that be nice? :-)
Yes, definitely, but it would be nicer still if the configuration
maintainer faced that question, and I just did apt-get upgrade... :-)
-------

Anyway, as you see the 6 levels described are like thresholds in "change
severity" which means that for example, given package Y with history
like this:

Release 1.22
Update 1: classified as 1 (Guaranteed behavior preserving)
Update 2: classified as 2 (Behavior extensions)
Update 3: classified as 1 (Guaranteed behavior preserving)
Release 1.23 (max level above is 2 so the release is classified as
"Behavior extensions" compared to 1.22)
Update 4: classified as 3 (Likely to be behavior preserving)
Update 5: classified as 2 (Behavior extensions)
Update 6: classified as 4 (Compatible)
Release 1.24 (max level above is 4 so the release is classified as
"Compatible" compared to 1.23)
Update 7: classified as 5 (Likely non compatible)
Update 8: classified as 4 (Compatible)
Release 1.25 (max level above is 5 so the release is classified as
"Likely non compatible" compared to 1.24)
Update 9: classified as 6 (Non compatible)
Update 10: classified as 1 (Guaranteed behavior preserving)
Release 1.3 (max level above is 6 so the release is classified as "Non
compatible" compared to 1.25)

So if package X is dependent on Y 1.22 then it could definitely stretch
to 1.23, note also that level 1-2 are automatically computable. With
good probability, but we need to trust the developer of X on this we
could even try out 1.24. Going to 1.25 is gambling, but still has a
chance of working. 1.3 is non compatible so if that works the developer
of X is simply wrong in his judgement! About 0.001 chance I guess.

Personally I think this could be really useful and when/if we decide to
add support for individual package update streams in SqueakMap (which I
think we should ASAP) then this little classification scheme above would
fit perfectly. And note - it would still be optional and we would still
be using ChangeSets. :-)

But sure, a version numbering scheme is quite ok too. And of course it
would be optional to follow.

regards, Göran