Mail Archives: cygwin/2012/08/19/15:29:51
Yeah, we won't be forking a new version... We'll either go commercial via Red Hat or select a 1.7.x version that works for us. We want to be part if the effort and contribute as such.
The real spirit of my question was this.... We develop software ourselves, and sometimes we put out a "stable / production" version which we know has more unproven features, or has undergone some major refactoring, and inspite of QA and testing and we expect more bugs. At other times, we know that we've got a stable release and it's proven to work well.
The spirit of my question "which version do you like" was in that light. I follow the cygwin list, and constantly see reports of bugs and fixes, and use this snapshot or that... Great work for sure. It's hard for me to evaluate when the bugs are minor, or, where there has been a major refactoring and all the bugs are getting worked out.
Thanks,
Devin
On Aug 19, 2012, at 12:25 PM, "Christopher Faylor" wrote:
> On Sun, Aug 19, 2012 at 01:17:24PM +0400, Andrey Khalyavin wrote:
>> On 08/17/2012 04:13 PM, Devin Nate wrote:
>>> My question, of the Cygwin users (or developers), which version would you select if your goal was maximum stability?
>>
>> Our experience is that they are all not particularly reliable (we
>> haven't checked all 1.7.* versions though). If you want
>> to make your script more stable, add retry logic and make it as more
>> serial as possible.
>
> The best way to achieve stability in Cygwin or any software project is
> by offering up some effort and providing good bug reports and test cases
> so that we can fix problems. That would tend to make the latest version
> the most stable.
>
> Even better would be to gain understanding in how Cygwin works and offer
> improvements yourself.
>
>> Unless you want to create your own version of cygwin of course. You
>> can try to backport all important crash and bug fixes
>> to an older version. Then the most recent versions (1.7.15 and 1.7.16)
>> are probably the best since backports will be easier.
>
> That would be a continuing battle and it would also be rather selfish.
> If you are going to gain enough knowledge to figure out what's important
> and how to backport it you might as well do the rest of the world some
> good too and help improve things for the real Cygwin project rather than
> your fork of it.
>
> cgf
>
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -