Dominic Laflamme writes:
> is there an "SDK-only" distribution somewhere (.h + .lib)?

As I happen to have a fresh build of GIMP 2.2, I guess I could provide a such, if Jernej doesn't want to.

Get www.gimp.org/win32/gimp-2.2.8.zip. Please tell me if there is anything missing in it. (It contains only gcc import libraries (.a files), but you can generate Microsoft import libraries (.lib files) from the .def files that are included.)

(Don't worry that the name has "2.2.8" in it, that's just because the version number i CVS already has been bumped to 2.2.8. The headers and import libs should work fine for older GIMP 2.2.x, too.)

--tml

Tor Lillqvist writes:
> Get www.gimp.org/win32/gimp-2.2.8.zip.

Oops, I meant gimp-dev-2.2.8.zip.

--tml

Hi,

Tor Lillqvist writes:

Get www.gimp.org/win32/gimp-2.2.8.zip. Please tell me if there is anything missing in it. (It contains only gcc import libraries (.a files), but you can generate Microsoft import libraries (.lib files) from the .def files that are included.)

(Don't worry that the name has "2.2.8" in it, that's just because the version number i CVS already has been bumped to 2.2.8. The headers and import libs should work fine for older GIMP 2.2.x, too.)

Tor, could you please consider to rename that zip file? Having files with the 2.2.8 version floating around on gimp.org is IMO a very bad idea.

Sven

Sven Neumann writes:
> Tor, could you please consider to rename that zip file? Having files > with the 2.2.8 version floating around on gimp.org is IMO a very bad > idea.

OK, done. It's now gimp-dev-2.2.7.zip.

--tml

Sven Neumann writes:
> Having files with the 2.2.8 version floating around on gimp.org is > IMO a very bad idea.

(Hmm, but that version number is floating around publicly in CVS ;-)

This is an excellent opportunity to bring up an idea I have tried to suggest a few times without success:

Currently some modules in GNOME CVS bump the micro version number right after a source release. Others bump right before a release. And some bump at a random time between releaes. This is IMHO confusing, as can be seen from this case.

My idea is that the official policy would be to use both pre- and post-release bumps. Only in a release tarball would the micro version number be odd. As soon as the release has been done, the micro version number would be bumped. And then immediately before making the next release it would be bumped again. Then there would be no confusion. An odd micro number would always indicate an official source release, and an even micro number a CVS snapshot. Stuff built from CVS snapshots could use the version number from CVS at the time without risking being confised with the next official version.

--tml

Hi,

Tor Lillqvist writes:

Currently some modules in GNOME CVS bump the micro version number right after a source release. Others bump right before a release. And some bump at a random time between releaes. This is IMHO confusing, as can be seen from this case.

My idea is that the official policy would be to use both pre- and post-release bumps. Only in a release tarball would the micro version number be odd. As soon as the release has been done, the micro version number would be bumped. And then immediately before making the next release it would be bumped again. Then there would be no confusion. An odd micro number would always indicate an official source release, and an even micro number a CVS snapshot. Stuff built from CVS snapshots could use the version number from CVS at the time without risking being confised with the next official version.

in my opinion this would only make things even more confusing. A CVS snapshot should be clearly labelled as such, not implicitely by the micro version number being odd or even. What about using something like gimp-2.2.8-cvs-20050523.zip for cvs snapshots?

Sven

Sven Neumann writes:
> in my opinion this would only make things even more confusing.

How, exactly? Because the procedure for person doing a release would be a few steps longer? Or because people would wonder why each other version is missing when looking at some version history or ftp server directory list?

> What about using something like gimp-2.2.8-cvs-20050523.zip for cvs > snapshots?

Well, for Win32 distributions of GIMP stuff, where such files are handled manually, and/or people have "out-of-band" knowledge that 2.2.8 wasn't released yet at 2005-05-23, that presumably is clear enough.

But if one considers various Unix/Linux package management software, do they understand that for some packages "2.2.8-cvs-20050523" is earlier than "2.2.8", but on the other hand, for some other package, "1.2.3-cvs-20050523" would be later than "1.2.3" ?

--tml

Hi,

Tor Lillqvist writes:

How, exactly? Because the procedure for person doing a release would be a few steps longer? Or because people would wonder why each other version is missing when looking at some version history or ftp server directory list?

How are people supposed to know about this versioning scheme? Not all packages will use it; so how is a user supposed to know that even is stable, odd is some cvs snapshot?

What about using something like gimp-2.2.8-cvs-20050523.zip for

> cvs snapshots?

Well, for Win32 distributions of GIMP stuff, where such files are handled manually, and/or people have "out-of-band" knowledge that 2.2.8 wasn't released yet at 2005-05-23, that presumably is clear enough.

But if one considers various Unix/Linux package management software, do they understand that for some packages "2.2.8-cvs-20050523" is earlier than "2.2.8", but on the other hand, for some other package, "1.2.3-cvs-20050523" would be later than "1.2.3" ?

Well, then don't include a version number at all. That's how CVS snapshots are typically labelled, by nothing but the date.

Sven