This is the mail archive of the
mailing list for the Cygwin project.
Re: snapshots: first resort, or last resort?
Science Guy wrote:
Excellent point Joe (aka Science Guy!).
In http://cygwin.com/ml/cygwin/2006-06/msg00434.html, Brian said
latest snapshot should always be the first thing you try when
problem before reporting it to the list."
However, the instructions for installing snapshots at
are you sure you want to do this? Snapshots are risky. They have not
tested. Use them ONLY if there is a feature or bugfix that you need
and you are willing to deal with any problems, or at the request of a
For a non-expert, such as me, this dichotomy of views is perplexing.
is made all the more perplexing because there does not seem to be (I
not find) a user-readable list of bugs that each snapshot fixes
the latest release. So how would a user know whether the "risky"
installing a snapshot will have any chance of fixing a particular bug?
If you have a problem, you should try a snapshot. However, you should
keep in mind that doing so means trying a potentially unstable setup.
Therefore, when trying a snapshot, you should do as little as possible
while using that snapshot. If it doesn't fix your problem, it is
safest to go back to a stable version. If it does, *then* you have to
decide if you want to use a setup that might be unstable (more so than
usual), or if you can wait for an official release.
Which begs the question -- why aren't releases done more often? Five
months between releases seems intensely long compared to, say, the linux
kernel, which averaged 1 month releases when 2.4 was active, to 2 month
releases, now, with 2.6 and the managed "bug fix" releases that happen in
between regular releases.
It doesn't do _users_ alot of good to check a snapshot. It does,
indirectly, in that it may increase code quality, *but*, if they don't want
to run with an unstable snapshot, they won't see their bugfix for [several?]
Trying a snapshot fine for testing a particular bugfix, but snapshots
are no substitute for updating the released product on a regular basis. If
the cost to do a release is low and number of changes / bugfixes are high,
it would be good to get the product to a "releasable" point every few weeks
to a month so users will see their efforts at find/isolating/reporting/
trying snapshots, rewarded. Is there some obstacle to more regular
If it were me, (and I know it's not, thank-you), I'd feel better about
getting updated releases into user's hands as soon as reasonable. If I fix
something, or change something, I wouldn't want to wait 6 months to release
it, (ideally,) so if a change I make introduces an untested and unthought-of
incompatibility I'm more likely to remember the changes that went into the
code. Five-Six months later, on active code and the changes might as well
have been made by someone else and I'm more likely to have to go in "cold"
to figure out which change broke things for some isolated user test case.
If there have been many changes, it's all the more difficult to find out
which change introduced the problem (IMNSHO).
I would take advantage of the "Test" release present in setup to give
people time to check things, then rotate it into the "Current" slot, and the
older one to "Previous". I know other people have different working styles,
but it helps to understand where they are coming from and their rationale
for doing it the way they do it.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html