I have changed the AppVeyor settings so that the AppVeyor build number
mirrors the Csound version number. We now will have 6.10.{build} as
the build number.

This should be carried forward into the Windows installer and zip file.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com

I'm going to need something like that for the online installer. I was
thinking about using global env variables in .travis.yml and sed rather
than hard-coding the version numbers at each tagged commit.


On 21/11/17 13:43, Michael Gogins wrote:
> I have changed the AppVeyor settings so that the AppVeyor build number
> mirrors the Csound version number. We now will have 6.10.{build} as
> the build number.
>
> This should be carried forward into the Windows installer and zip file.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com

I think we should adopt global environment variables prefixed with
"CSOUND_APPVEYOR_" for all such data.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, Nov 21, 2017 at 5:19 PM, Guillermo Senna  wrote:
> I'm going to need something like that for the online installer. I was
> thinking about using global env variables in .travis.yml and sed rather
> than hard-coding the version numbers at each tagged commit.
>
>
> On 21/11/17 13:43, Michael Gogins wrote:
>> I have changed the AppVeyor settings so that the AppVeyor build number
>> mirrors the Csound version number. We now will have 6.10.{build} as
>> the build number.
>>
>> This should be carried forward into the Windows installer and zip file.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com

OK, and "CSOUND_TRAVIS_OSX_" for Travis OSX deployment or how do you
prefer that?


On 21/11/17 23:14, Michael Gogins wrote:
> I think we should adopt global environment variables prefixed with
> "CSOUND_APPVEYOR_" for all such data.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Nov 21, 2017 at 5:19 PM, Guillermo Senna  wrote:
>> I'm going to need something like that for the online installer. I was
>> thinking about using global env variables in .travis.yml and sed rather
>> than hard-coding the version numbers at each tagged commit.
>>
>>
>> On 21/11/17 13:43, Michael Gogins wrote:
>>> I have changed the AppVeyor settings so that the AppVeyor build number
>>> mirrors the Csound version number. We now will have 6.10.{build} as
>>> the build number.
>>>
>>> This should be carried forward into the Windows installer and zip file.
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com

Replying to myself: I have some more thinking to do regarding Travis.
Although we agreed not to use the online installer for Linux, maybe a
global CSOUND_TRAVIS_VERSION would be OK too.


On 21/11/17 23:17, Guillermo Senna wrote:
> OK, and "CSOUND_TRAVIS_OSX_" for Travis OSX deployment or how do you
> prefer that?
>
>
> On 21/11/17 23:14, Michael Gogins wrote:
>> I think we should adopt global environment variables prefixed with
>> "CSOUND_APPVEYOR_" for all such data.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Tue, Nov 21, 2017 at 5:19 PM, Guillermo Senna  wrote:
>>> I'm going to need something like that for the online installer. I was
>>> thinking about using global env variables in .travis.yml and sed rather
>>> than hard-coding the version numbers at each tagged commit.
>>>
>>>
>>> On 21/11/17 13:43, Michael Gogins wrote:
>>>> I have changed the AppVeyor settings so that the AppVeyor build number
>>>> mirrors the Csound version number. We now will have 6.10.{build} as
>>>> the build number.
>>>>
>>>> This should be carried forward into the Windows installer and zip file.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com

Hi Michael,

I think this is not the same format as what we have been using for a
while now.  If you check out include/version.h, we have
MAJOR.MINOR.PATCH and no build.  I think that producing artifacts with
the build numbering you setup is misleading compared to our version
numbering system, and is not in sync with what is done in other
platforms/releases.

steven


On Tue, Nov 21, 2017 at 8:43 AM, Michael Gogins
 wrote:
> I have changed the AppVeyor settings so that the AppVeyor build number
> mirrors the Csound version number. We now will have 6.10.{build} as
> the build number.
>
> This should be carried forward into the Windows installer and zip file.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com

I've seen that Qt internally uses semantic versioning along with the
date of the build. Maybe MAJOR.MINOR.PATCH_BUILD could be a compromise?



On 26/11/17 01:25, Steven Yi wrote:
> Hi Michael,
>
> I think this is not the same format as what we have been using for a
> while now.  If you check out include/version.h, we have
> MAJOR.MINOR.PATCH and no build.  I think that producing artifacts with
> the build numbering you setup is misleading compared to our version
> numbering system, and is not in sync with what is done in other
> platforms/releases.
>
> steven
>
>
> On Tue, Nov 21, 2017 at 8:43 AM, Michael Gogins
>  wrote:
>> I have changed the AppVeyor settings so that the AppVeyor build number
>> mirrors the Csound version number. We now will have 6.10.{build} as
>> the build number.
>>
>> This should be carried forward into the Windows installer and zip file.
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com

We have the Git Commit id's as part of our csound console output and
that lets us identify exactly what source code was used to build the
program.  I'd argue that the commit information is more useful than
using an arbitrary build number and it gives precise information that
any developer on any platform can reference easily when looking at
issues. (E.g., User reports bug on Windows with commit Id xxxxx,
developer on Linux or OSX might be able to look at the commit id and
help diagnose without having to look up build number on Appveyor and
cross-reference it with commit ID).

Outside of Semantic Versioning conventions, I've seen things like
Guillermo has mentioned but using an additional suffix, something like
"8.0.1-beta0". I think having the different separator (i.e., "-"
instead of ".") is useful.  I use a similar format myself for Blue,
where versioning is three-part, but beta or dev labels are added at
end and it is both a part of the versioning information internally
within the program as well as in the filenames of the releases.
(i.e., if I have a dev build, the program shows "2.7.3_dev" in the
title and the file they download is "blue_2.7.3_dev.zip"). If a build
number or date is going to be used with dev builds of Csound, it might
be nice to have it have "major.minor.patch-date" or
"major.minore.patch-buildnum".

On Sat, Nov 25, 2017 at 8:55 PM, Guillermo Senna  wrote:
> I've seen that Qt internally uses semantic versioning along with the
> date of the build. Maybe MAJOR.MINOR.PATCH_BUILD could be a compromise?
>
>
>
> On 26/11/17 01:25, Steven Yi wrote:
>> Hi Michael,
>>
>> I think this is not the same format as what we have been using for a
>> while now.  If you check out include/version.h, we have
>> MAJOR.MINOR.PATCH and no build.  I think that producing artifacts with
>> the build numbering you setup is misleading compared to our version
>> numbering system, and is not in sync with what is done in other
>> platforms/releases.
>>
>> steven
>>
>>
>> On Tue, Nov 21, 2017 at 8:43 AM, Michael Gogins
>>  wrote:
>>> I have changed the AppVeyor settings so that the AppVeyor build number
>>> mirrors the Csound version number. We now will have 6.10.{build} as
>>> the build number.
>>>
>>> This should be carried forward into the Windows installer and zip file.
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com

Of course having the build number in the release filename does not
remove the commit number.

The build number is for people looking at the AppVeyor artifact pages
or the GitHub releases.

After reading the semantic versioning proposal and some comments and
questions, how about:

Csound-{os}-{architecture}-MAJOR.MINOR.PATCH-{status}-{build}.ext

E.g.

Csound_Windows_x64-6.10.01-rc2-298.exe
Csound_Windows_x64-6.10.01-rc2-298.zip

Best,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Sun, Nov 26, 2017 at 2:34 PM, Steven Yi  wrote:
> We have the Git Commit id's as part of our csound console output and
> that lets us identify exactly what source code was used to build the
> program.  I'd argue that the commit information is more useful than
> using an arbitrary build number and it gives precise information that
> any developer on any platform can reference easily when looking at
> issues. (E.g., User reports bug on Windows with commit Id xxxxx,
> developer on Linux or OSX might be able to look at the commit id and
> help diagnose without having to look up build number on Appveyor and
> cross-reference it with commit ID).
>
> Outside of Semantic Versioning conventions, I've seen things like
> Guillermo has mentioned but using an additional suffix, something like
> "8.0.1-beta0". I think having the different separator (i.e., "-"
> instead of ".") is useful.  I use a similar format myself for Blue,
> where versioning is three-part, but beta or dev labels are added at
> end and it is both a part of the versioning information internally
> within the program as well as in the filenames of the releases.
> (i.e., if I have a dev build, the program shows "2.7.3_dev" in the
> title and the file they download is "blue_2.7.3_dev.zip"). If a build
> number or date is going to be used with dev builds of Csound, it might
> be nice to have it have "major.minor.patch-date" or
> "major.minore.patch-buildnum".
>
> On Sat, Nov 25, 2017 at 8:55 PM, Guillermo Senna  wrote:
>> I've seen that Qt internally uses semantic versioning along with the
>> date of the build. Maybe MAJOR.MINOR.PATCH_BUILD could be a compromise?
>>
>>
>>
>> On 26/11/17 01:25, Steven Yi wrote:
>>> Hi Michael,
>>>
>>> I think this is not the same format as what we have been using for a
>>> while now.  If you check out include/version.h, we have
>>> MAJOR.MINOR.PATCH and no build.  I think that producing artifacts with
>>> the build numbering you setup is misleading compared to our version
>>> numbering system, and is not in sync with what is done in other
>>> platforms/releases.
>>>
>>> steven
>>>
>>>
>>> On Tue, Nov 21, 2017 at 8:43 AM, Michael Gogins
>>>  wrote:
>>>> I have changed the AppVeyor settings so that the AppVeyor build number
>>>> mirrors the Csound version number. We now will have 6.10.{build} as
>>>> the build number.
>>>>
>>>> This should be carried forward into the Windows installer and zip file.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com

That sounds good to me and is pretty close to what are already using
for the other releases:

https://github.com/csound/csound/releases/tag/6.09.1

I'd recommend to have it match the other platforms, so more like your
formatted string rather than the examples:

csound-windows-x64-6.10.0-rc2-298.exe

Also, for releases, I'd rather like no status and no build info, so
for the 6.10.0 release:

csound-windows-x64-6.10.0.exe

The changes should also make it easier to find as it will get grouped
with the other platform releases by sort order.  (As it is now, the
Setup_Csound...exe is coming up after the manual releases.)

On Sun, Nov 26, 2017 at 5:53 PM, Michael Gogins
 wrote:
> Of course having the build number in the release filename does not
> remove the commit number.
>
> The build number is for people looking at the AppVeyor artifact pages
> or the GitHub releases.
>
> After reading the semantic versioning proposal and some comments and
> questions, how about:
>
> Csound-{os}-{architecture}-MAJOR.MINOR.PATCH-{status}-{build}.ext
>
> E.g.
>
> Csound_Windows_x64-6.10.01-rc2-298.exe
> Csound_Windows_x64-6.10.01-rc2-298.zip
>
> Best,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Sun, Nov 26, 2017 at 2:34 PM, Steven Yi  wrote:
>> We have the Git Commit id's as part of our csound console output and
>> that lets us identify exactly what source code was used to build the
>> program.  I'd argue that the commit information is more useful than
>> using an arbitrary build number and it gives precise information that
>> any developer on any platform can reference easily when looking at
>> issues. (E.g., User reports bug on Windows with commit Id xxxxx,
>> developer on Linux or OSX might be able to look at the commit id and
>> help diagnose without having to look up build number on Appveyor and
>> cross-reference it with commit ID).
>>
>> Outside of Semantic Versioning conventions, I've seen things like
>> Guillermo has mentioned but using an additional suffix, something like
>> "8.0.1-beta0". I think having the different separator (i.e., "-"
>> instead of ".") is useful.  I use a similar format myself for Blue,
>> where versioning is three-part, but beta or dev labels are added at
>> end and it is both a part of the versioning information internally
>> within the program as well as in the filenames of the releases.
>> (i.e., if I have a dev build, the program shows "2.7.3_dev" in the
>> title and the file they download is "blue_2.7.3_dev.zip"). If a build
>> number or date is going to be used with dev builds of Csound, it might
>> be nice to have it have "major.minor.patch-date" or
>> "major.minore.patch-buildnum".
>>
>> On Sat, Nov 25, 2017 at 8:55 PM, Guillermo Senna  wrote:
>>> I've seen that Qt internally uses semantic versioning along with the
>>> date of the build. Maybe MAJOR.MINOR.PATCH_BUILD could be a compromise?
>>>
>>>
>>>
>>> On 26/11/17 01:25, Steven Yi wrote:
>>>> Hi Michael,
>>>>
>>>> I think this is not the same format as what we have been using for a
>>>> while now.  If you check out include/version.h, we have
>>>> MAJOR.MINOR.PATCH and no build.  I think that producing artifacts with
>>>> the build numbering you setup is misleading compared to our version
>>>> numbering system, and is not in sync with what is done in other
>>>> platforms/releases.
>>>>
>>>> steven
>>>>
>>>>
>>>> On Tue, Nov 21, 2017 at 8:43 AM, Michael Gogins
>>>>  wrote:
>>>>> I have changed the AppVeyor settings so that the AppVeyor build number
>>>>> mirrors the Csound version number. We now will have 6.10.{build} as
>>>>> the build number.
>>>>>
>>>>> This should be carried forward into the Windows installer and zip file.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com