Mail Archives: cygwin-developers/2003/02/08/12:15:07
On Sat, Feb 08, 2003 at 12:04:16PM -0500, Igor Pechtchanski wrote:
>On Sat, 8 Feb 2003, Christopher Faylor wrote:
>
>> The subject says it all. If I don't distribute the mingw and w32api
>> sources, I stand the chance of releasing a version of the sources that
>> won't build until the next release of mingw or w32api. I don't want to
>> have to go through the effort of coordinating with Earnie every time I
>> release cygwin so the alternative is to go back to including the mingw
>> and w32api sources in the cygwin source tarball.
>>
>> I don't like the thought of duplication here but I guess I've finally
>> grown weary of the bug reports from people who can't build from the
>> sources available via tarball.
>>
>> I could include a top-level readme file in the source directory saying
>> that the w32api and mingw directories are just snapshots and are not
>> intended for installation. Or, I could install up a top-level readme
>> that says "Don't be a schmuck. Use CVS." Or, I could just keep pointing
>> at the FAQ and refining it as we go along.
>>
>> So, which is the "meanest" alternative here? I honestly don't know and
>> am willing to go with whatever people suggest.
>>
>> Btw, please don't cc this thread to the cygwin mailing list. I sent it
>> here for a reason. I don't want to open up discussion to everybody in
>> the world.
>
>I know the tags are just for your convenience, and you wouldn't want to
>tag the whole repository anyway for Cygwin releases, but could we,
>perhaps, just have a file somewhere with the exact checkout dates of each
>packaged Cygwin release (e.g. "RELEASES" in the winsup/cygwin directory)?
>That way, if anyone wanted to build some particular release, they could
>just check out from CVS with the appropriate date, and they wouldn't need
>any tags at all. Plus, you wouldn't need to include w32api and mingw
>directories in the source tarball, and the source tarball could be just
>for reference.
You should be able to easily infer the time from the ChangeLog. I can
make the ChangeLog more explicit so that it says more than "bump dll
minor number".
I don't like having separate files containing information that can be
derived already. There is always the possibility that things will
go out of sync.
Maybe that is the answer. The FAQ could say "look at the ChangeLog for
the date of the release and use cvs to check out on that date".
cgf
- Raw text -