Re: [fltk.development] RFC: decision on license to useforfltk/examplessource code

2013-03-01 Thread Albrecht Schlosser
On 01.03.2013 04:16, Michael Sweet wrote: On 2013-02-28, at 8:24 PM, Albrecht Schlosser ... wrote: IIRC I haven't seen a real freeware (public domain) proposal. Wouldn't this be appropriate for the example code? Unfortunately, public domain isn't a universally-recognized status for

Re: [fltk.development] FLTK version number update and release process [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packaged properly]

2013-03-01 Thread MacArthur, Ian (Selex ES, UK)
1) For large commercial software, I have a VERSION file in the main directory with a single line in it: VERSION=#.# This can be include'ed from Makefiles to define macros used on everything from compile lines to Makefile construction

Re: [fltk.development] RFC: decision on license to use forfltk/examplessource code

2013-03-01 Thread MacArthur, Ian (Selex ES, UK)
IIRC I haven't seen a real freeware (public domain) proposal. Wouldn't this be appropriate for the example code? I see Mike's already said this, but thought I'd re-iterate: way back when, in my naivety, I went looking for a Public Domain license, and was told that such a thing really doesn't

Re: [fltk.development] FLTK version number update and release process [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packaged properly]

2013-03-01 Thread Peter Åstrand
On Fri, 1 Mar 2013, MacArthur, Ian (Selex ES, UK) wrote: Oh, and another question: WHEN do we upgrade the version number(s)? (a) immediately after one release, for the next release, or What Mike said: As soon as *anything* in SVN changes after a release, we need to bump the version

Re: [fltk.development] FLTK version number update and releaseprocess [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packagedproperly]

2013-03-01 Thread Albrecht Schlosser
On 01.03.2013 11:55, Peter Åstrand wrote: Suggestion: After the release is done, append post to the version number. The version number must be numeric, three parts only, see: http://www.fltk.org/doc-1.3/enumerations.html The FLTK version number is stored in a number of compile-time constants:

Re: [fltk.development] FLTK version number update and releaseprocess [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packagedproperly]

2013-03-01 Thread Greg Ercolano
On 03/01/13 01:33, MacArthur, Ian (Selex ES, UK) wrote: What Mike said: As soon as *anything* in SVN changes after a release, we need to bump the version numbers in some way. Or, just change it immediately after release. Changing the version number is itself a change, and would

Re: [fltk.development] FLTK version number update and releaseprocess [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packagedproperly]

2013-03-01 Thread Ian MacArthur
On 1 Mar 2013, at 15:39, Greg Ercolano wrote: On 03/01/13 01:33, MacArthur, Ian (Selex ES, UK) wrote: What Mike said: As soon as *anything* in SVN changes after a release, we need to bump the version numbers in some way. Or, just change it immediately after release. Changing

Re: [fltk.development] FLTK version number update andreleaseprocess [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2tarball not packagedproperly]

2013-03-01 Thread Greg Ercolano
Not sure what that number becomes if we ever move to git, though.. What it becomes, as you know, is a human-opaque string of gibberish... (Technically I understand why it is like that, but I really can't believe we couldn't figure out some way to hide that behind some human-friendly