Version tracking (was: Starting a Magma/Seaside pilot project)

[Chris Muller]

Hi, I have also been thinking about this.  While there
is a #magmaVersion which returns simply an Integer,
this is used primarily to check against legacy files. 
i.e., if there is no format change for a new release,
I don't increment it.

It would seem useful to have another human-consumable
versionString.  To this end I have considered

  "1.0" to be the functionality included right now
  "1.1" (real soon now) which interfaces to the
security module and
  "1.2" (vaporware) to be the one which includes
security AND the import/export replication feature

It would be real great if these could be
file-compatible with each other but I don't know
whether that will be possible yet.

Also, as incremental enhancements/bug fixes, each of
these would be suffixed with "r1", "r2", etc.

Whew, lots o' work to do..

Thanks,
 Chris

--- "David T. Lewis" <lewis at mail.msen.com> wrote:

> On Thu, Dec 22, 2005 at 01:39:30PM +0100, Cees De
> Groot wrote:
> > On 12/22/05, Brent Pinkney
> <brent.pinkney at aircom.co.za> wrote:
> > > It would be appreciated it you could suggest a
> light-weight
> > > mechanism you would like to use for this.
> > >
> >
> > The lightest-weight mechanism I know of is
> MonticelloConfigurations.
> > But I'm not sure whether kilana.unibe.ch has
> already been updated to
> > accept .mcm files.
> 
> It might be too obvious to mention, but for a
> package such as Magma
> that is maintained independently outside of the main
> image, a simple
> version label can also be quite helpful. For
> example, in the OSProcess
> package, there is a class called OSProcess with this
> class-side method:
> 
> versionString
>     "OSProcess versionString"
>     ^'4.0.1'
> 
> Just use some version numbering convention that
> makes sense to you,
> and make sure you update it in your development
> image right after you
> publish a new release on Squeak Map. Use Montecello
> etc for the real
> version control, and keep the release names on
> Squeak Map in sync
> with your versionString.
> 
> Along with keeping track of versions, this is
> helpful if you are
> maintaining a lot of unit tests, and you want other
> people to
> run them and report results back to you. For
> example, if you run
> "OSProcess allTestResults", the versionString for
> several packages
> and plugins are collected along with the test
> results (also the
> operating system, machine word size, etc).
> 
> Note that class VersionNumber does some useful
> things (but I still
> maintain a version string so I can have e.g.
> '4.2alpha').
> 
> Dave
> 
> 
>