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.
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?