When we send it patches to fptools/libraries that change the API, should we include a patch to increment the version number too? For example, I have a patch that adds bindings for WaitForMultipleObjects and WaitForSingleObject to the Win32 package. Should I increase the Win32 package's version number in the patch I send? Also, now Hugs is building again on Windows (at least the command-line part) and perhaps there will be a release of (Win)Hugs soon. It would be convenient to be able to say that the next release of Hugs comes with, e.g. Win32-1.1 and HaXml-1.13.1. Thanks, Brian
On Fri, Jul 29, 2005 at 06:41:23PM -0500, Brian Smith wrote:
When we send it patches to fptools/libraries that change the API, should we include a patch to increment the version number too? For example, I have a patch that adds bindings for WaitForMultipleObjects and WaitForSingleObject to the Win32 package. Should I increase the Win32 package's version number in the patch I send?
That would be tedious -- incrementing on release seems more reasonable. Note that the graphics part of the Win32 package fails under GHC.
On 7/29/05, Ross Paterson
On Fri, Jul 29, 2005 at 06:41:23PM -0500, Brian Smith wrote:
When we send it patches to fptools/libraries that change the API, should we include a patch to increment the version number too? For example, I have a patch that adds bindings for WaitForMultipleObjects and WaitForSingleObject to the Win32 package. Should I increase the Win32 package's version number in the patch I send?
That would be tedious -- incrementing on release seems more reasonable.
Okay. But, then how can I document that these new functions are not in Win32-1.0? I would like to say, for example "Introduced in version 1.1" in the documentation. That is what made me think that the version number needs to be bumped (only) during the first API change after a release. Note that the graphics part of the Win32 package fails under GHC. Do you know why? I noticed that when I build Win32 using Cabal, genericWndProc and DeleteObject do not get linked correctly. I think it is a problem with "dynamic" imports. But, I don't know if it is related to the problem you are talking about. - Brian
On Sun, Jul 31, 2005 at 01:50:20PM -0500, Brian Smith wrote:
Okay. But, then how can I document that these new functions are not in Win32-1.0? I would like to say, for example "Introduced in version 1.1" in the documentation. That is what made me think that the version number needs to be bumped (only) during the first API change after a release.
These intermediate versions differ from 1.0, but they will also differ from 1.1, and each other. If you build a source distribution with setup sdist --snapshot, they will be given versions 1.0.YYYYMMDD, which lie between the two. This works if you increment on release (and don't change the depth of numbering).
Note that the graphics part of the Win32 package fails under GHC.
Do you know why? I noticed that when I build Win32 using Cabal, genericWndProc and DeleteObject do not get linked correctly. I think it is a problem with "dynamic" imports. But, I don't know if it is related to the problem you are talking about.
I have no personal experience with it. SimonM reported:
[The test programs] still don't do much. If I compile with -threaded, then the HelloWorld program pops up a window, but the cursor is an hour glass and it doesn't do anything else. The [HGL examples] either hang, or if I use -threaded they re-enter the scheduler.
participants (2)
-
Brian Smith -
Ross Paterson