Re: [MinGW-dvlpr] Catalogue package naming

[Keith M. <kei...@us...>]

On 26/09/13 23:32, Earnie Boyd wrote:
> Now that I've started working with the mingw-dist catalogue system and
> understanding some nuances and such I'm going to suggest something
> that will help with affiliate package naming for the GUI.

How exactly?  The affiliation mechanism is rather more static than you
seem to assume; furthermore, while I've already extended it to support
affiliation at the component package level, extending it to the release
level is not something I wish to contemplate.

> What I'm thinking is a categorical package naming system.  Using
> package foo as an example I'm thinking that we could have a
> mingw32-current-foo package a mingw32-previous-foo package and a
> mingw32-history-foo package.  The history package would contain all
> the packages older than previous.

Too abstract.  Too arbitrary.  To awkward to maintain.  Too ephemeral.

> I am also thinking that we have package names of
> mingw32-current-ancillary-foo, etc where the mingw-current-foo would
> contain the primary binary files and the ancillary package would
> contain the documentation and other non-required files for the binary
> package.  By doing this we can present the user with a better GUI
> presentation based on the affiliate grouping.
> 
> Thoughts?

I'm in favour of segregating core and ancilliary components into
separate logical package containers, within common package-collections;
(I advocated as much on https://sourceforge.net/p/mingw/bugs/2028/).

I'm not in favour of the current --> previous --> historical notion.
Most, if not all, of our users should be sufficiently numerate to
interpret a progression of version numbers.  mingw-get already shows
"current" version of each package, (as "Repository Version").  I plan to
enumerate all other mingw-get installable versions, on the GUI's
"Versions" information tab; surely that will suffice?

-- 
Regards,
Keith.