Naming Scheme for MacPorts Octave versions

[Ryan Schmidt]

On Dec 12, 2011, at 20:17, Michael Dickens wrote:

> Forwarded with permission from Lukas.  I just use Octave (-devel) in a basic sense, so I'll trust what he says -- and, it makes sense too if folks are using octave (3.2) as well as *-devel (3.4).  But, as I'm trying to back off of doing this sort of work I'll defer to others to make any decision. - MLD
> 
> Begin forwarded message:
> 
> From: Lukas Reichlin <lukas.reichlin at gmail.com>
> Date: December 11, 2011 3:47:03 PM EST
> To: Michael Dickens <michaelld at macports.org>
> Subject: Naming Scheme for MacPorts Octave versions
> 
> Hi Michael
> 
> For reasons I don't understand, MacPorts "octave" port is still version 3.2.4. The current release, version 3.4.3, is only available as "octave-devel". Since Octave 3.6.0 will be available soon and we don't want an "octave-devel-devel", something needs to be done. Probably there are people who still want the outdated Octave 3.2, so I propose to change the port names as following:
> 
> octave32  (former octave)
> octave34  (former octave-devel)
> octave36  (when it is available)
> 
> This naming scheme is usual for python, gcc and since today with clang and llvm.
> 
> Additionaly, this name scheme should be applied to the extra packages as well, because they rely on certain octave versions:
> octave-control (1.0.11) becomes octave32-control, and a new octave34-control (2.2.3) could be added. This is similar to python, where we have py26-xyz, py27-xyz and so on.
> 
> What do you think?

That sounds reasonable. But it will be quite an undertaking. In addition to renaming the existing octave ports, and leaving stub ports with the old names to ease upgrades, the octave portgroup will have to become a "unified" portgroup, like the python portgroup did, and all the current octave module ports will have to be updated to work with that revised portgroup. If this can be done all at once by someone interested in this task, great; if not, the octave 1.0 portgroup should be copied to a new octave 1.1 portgroup and the changes made there, then ports can be gradually updated to the new 1.1 portgroup.