-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Roger, Ian,
I agree with Ian. The current version numbering is a mess. As far as I
can tell, the "latest" version of 15.53 was either v15.53f or v15.53g,
which morphed into v15.6 with Aaron's changes over Christmas and the new
year.
I think Roger is probably right when he proposes we start afresh with
version numbering for the first full OpenPoplog release, although I can
see some confusion arising when we are using a different version
numbering system from Aaron.
[Roger]
>just three quick points on this:
>
> 1. I'm not sure you're right about 15.53 - the previous stable
> release (for windows at least) was 15.5.
The v15.5 version for Windows was the "disk pack" version, with an
installer and components spread across numbered disk directories. There
was a v15.53 for Windows. Although it contained (and still contains)
bugs, (most notably the command-line/environment variable/directory/file
name Unicode/Ascii confusion fault), I wasn't aware that it was less
"stable" than v15.5. (Although there was always the sneaking suspicion
that, perhaps, the horse had bolted...).
I am not sure that it was ever correct to use a v15.5 or v15.53
designation for the Windows version while this lacked many of the
features present in, for example, the Linux version. I presume that the
"Linux Standard Base" (http://www.linuxbase.org/) approach to this
problem would be to declare a core Poplog with the version being
something like v15.6, with generic layers that have platform-specific
implementations overlaying the core, such that the standard Linux
release would be something like "Poplog Core v15.6 + XPoplog vX", while
the current Windows version would just be "Poplog Core v15.53 + WinPop
vY".
[Roger]
> 3. The kind of thing the 'openpoplog' team are thinking about
> probably do warrant a new version number, but my own view is that
> we should also go with a new name and start again at 1 (or 0?) ie
> OpenPoplog 1.0.0
Once we have achieved cross-platform compatibility for things such as
the relative coordinate graphics, XVED, etc., then I agree with you.
Before that, we probably need some layering system defining what
constitutes a given layer and what its version number should be.
It is incredibly easy to sit down and make changes to code, but
establishing good policies to ensure well-managed evolution of a
well-engineered system to match the needs of customers while ensuring
that all developers know the policies, understand the need for the
policies and operate according to the policies, is a much harder thing
to achieve, particularly in an open-source setting where most
contributors are volunteers with a limited amount of time to give who
are largely driven by external requirements of their own.
[Roger]
>I didn't know the even/odd thing - sounds like a good idea to me.
Agreed.
[Ian][... On the merits of "Development" versus "Stable" versions, and
an appropriate numbering convention]
I would like to see releases being made according to a pre-published
"road-map", wherever this might be achieved, with a simple mechanism to
proposing changes and accept them into the road-map. We hope that
OpenPoplog.org can provide the forum to achieve this.
(There is a draft "mind-map" of things that need to fit into the
OpenPoplog.org and OpenPoplog road-maps, at
http://www.openpoplog.org/freemind/test/OpenPoplogRoadMap.mm.html.
Please bear in mind that this is a work-in-progress. All suggestions or
proposals relating to the map should be sent to the
openpoplog-roadmap@lists.sourceforge.net. I have only just created this
list, so it may take up to 16 hours to be accessible).
[Ian]
>>So, please please please can you (whoever controls numbering - Aaron?)
>>consider renumbering v15.6 to v16.0.0 (v16 is required to start the new
>>version.release scheme) and quietly forget v15.6 as a bad idea. It's
>>likely you'll also want to construct a copy as v16.1.0 at the same time
>>for developers.
Regards,
- --
Jeff
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBQi8OJfHj+enJbeYqEQL5OwCdG+Jkb2BP2XhmiEb97DE4Vu/wyBkAoML1
c9eoScrsqExdBdBVpy6qQKGj
=8Jzm
-----END PGP SIGNATURE-----
|