This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

prev/curr/test behaviour


Has anyone tried HEAD since my update (I know, less that 24 hours :} ) ?

Specifically, the prev/curr/test behaviour is _potentially_ wrong.

Here's what I mean.

prev/curr/test can mean 1 of two things:
a:
the previous stable version,
the current stable version,
the test version

of given packages, or
b:
the previous stable version, or the current if no previous,
the current stable version,
the test version or the current if no previous.

Currently the reinstated buttons do a:. Now, if setup.ini always
provided prev and test, setup.exe would *appear* to do b to the users,
but actually do a:. This would be useful in certain circumstances.
i.e. when a package gets replaced by two packages that do what the
single one did, and the old package is removed, with a: it will
correctly uninstall. With b: it *won't*. (This can be address'd by
completely removing the package from the list, but that then breaks
*everyone(*)* who is running on previous for whatever reason - they get
forced to curr for the replacement package, ahead of time.

What I'm saying is that the behaviour in a: seems more sane to me, but
requires more management of setup.ini, whereas b: has less setup.ini
management, but also less capability to have different things in
prev/curr/test - reducing their value somewhat.

So, I'd like some input on this, as changing to b: is easy enough to do,
but I'd like to stay with a:, and doing that will affect upset at a
minimum.

Rob

(*) How many folk do run in the different 'dists'?



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]