Brave new (1.0) world.

Todd Olson tco2 at cornell.edu
Thu Feb 19 21:10:04 UTC 2009


Perhaps the release label is being asked to play too many roles?
Perhaps then there should be two labels?

   a) a release label
   b) an interface label


Users/Installers/System Integrators  have to wrestle with the question:

    'How much different is release B from release A?'

If the release labeling changes locked to time, then we have to know arcanea
like (a) 1.6 has major changes compared to 1.5 while (b) 1.7 is essentially
bug fixes compared to 1.6.  I find this very frustrating to use,
and also to explain to people I support.

On the other hand, as others explain, if release labeling is interface labeling
than what do you call the regular time driven releases if they don't 
correspond to the interface evolution?

So maybe two labels are needed?


For myself, what matters to me most as a user is interface labeling:
is B so significantly different than A that I can expect
to have to test (and maybe rework) everything that interfaces with it,
or is it just a bug fix and I can plug B in for A without problem,
and if I need I can down grade from B to A with out (interface) problems.
Or is it somewhere in between ... I can upgrade without problems
but something written for B might not work with A due to feature additions in B.

I don't really care about release labeling.


So I want a label that conveys something like the following about interfacing
and feature set

 <major change          -  code for A may break on B and B may break on A>
  -<minor change        -  code for A will work on B but B may break on A>
    -<invisible changes -  code for A will work on B and B will work on A>

             (invisible changes are things like bug fixed, performance tweaks
             (and yes these may change how code 'works' but at least the
             (user code compiles and runs.

In this scheme 1-9-0 is likely very different than 2-0-0
Also the parts can be multi character, so after 1-9 comes 1-10
if there are no major changes involved.

Maybe this labeling should not be load on top of a release label?
But if not, then how is this information conveyed to the users?

--
Regards,
Todd Olson


More information about the parrot-dev mailing list