Quantcast

Distinguishing Releases, RCs, Nightlies.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Distinguishing Releases, RCs, Nightlies.

James Crook
Gale wrote:

> We have no way to indicate an RC is an RC inside the app such that the user
>      might know. I don't see a solution until building is automatic, because
>      we probably don't want to rebuild just to turn a successful RC into a
>      release.

Automatic building (of installers / dmgs) won't solve it either. The
release would still have to be 'different' to the RC, and then it would
not be what we had tested.  We'd want to be 100% sure nothing had been
upgraded on the build machine between the RC being built and the release
build.


Instead I think our best option to providing status of a version is as
follows.

Currently 'Check Version' passes a single parameter:
http://www.audacityteam.org/download/?from_ver=2.1.3

It could pass more:
http://www.audacityteam.org/download/?from_ver=2.1.3&commitid=cf68891&sha256=b0fa790


This then needs a not very hard script on the server that matches the
versions and commit Ids.  The response page could then give a proper
identifier:
Audacity 2.1.3 RC1 of 10th-Jan-2017; Windows.

With this approach we can change that designation later by changing the
information in the script.  If RC1 becomes our release, we can now make
that script say:
Audacity 2.1.3 Official Release; Windows.


So we ask users to click on 'check version', and tell us what they see.  
We can also put the check version link in the about box too, if we want to.

--James




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Distinguishing Releases, RCs, Nightlies.

Vaughan Johnson-4
On Fri, Feb 10, 2017 at 6:50 AM, James Crook <[hidden email]> wrote:
> Gale wrote:
>
>> We have no way to indicate an RC is an RC inside the app such that the user
>>      might know.

Actually, we do.  We used to use it for betas.

The code would have to be updated for each RC, of course, but it's a
new build anyway.



>>I don't see a solution until building is automatic, because
>>      we probably don't want to rebuild just to turn a successful RC into a
>>      release.
>
> Automatic building (of installers / dmgs) won't solve it either. The
> release would still have to be 'different' to the RC, and then it would
> not be what we had tested.  We'd want to be 100% sure nothing had been
> upgraded on the build machine between the RC being built and the release
> build.
>
>
> Instead I think our best option to providing status of a version is as
> follows.
>
> Currently 'Check Version' passes a single parameter:
> http://www.audacityteam.org/download/?from_ver=2.1.3
>
> It could pass more:
> http://www.audacityteam.org/download/?from_ver=2.1.3&commitid=cf68891&sha256=b0fa790
>
>
> This then needs a not very hard script on the server that matches the
> versions and commit Ids.  The response page could then give a proper
> identifier:
> Audacity 2.1.3 RC1 of 10th-Jan-2017; Windows.
>
> With this approach we can change that designation later by changing the
> information in the script.  If RC1 becomes our release, we can now make
> that script say:
> Audacity 2.1.3 Official Release; Windows.
>
>
> So we ask users to click on 'check version', and tell us what they see.
> We can also put the check version link in the about box too, if we want to.
>
> --James
>
>

Interesting & +1.

But that's different than what shows in the app, right?

- V

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Distinguishing Releases, RCs, Nightlies.

Vaughan Johnson-4
Oops, falling asleep.  Didn't see that you answered the About Box aspect, too.
Thanks!

- V

On Mon, Feb 13, 2017 at 12:41 AM, Vaughan Johnson <[hidden email]> wrote:

> On Fri, Feb 10, 2017 at 6:50 AM, James Crook <[hidden email]> wrote:
>> Gale wrote:
>>
>>> We have no way to indicate an RC is an RC inside the app such that the user
>>>      might know.
>
> Actually, we do.  We used to use it for betas.
>
> The code would have to be updated for each RC, of course, but it's a
> new build anyway.
>
>
>
>>>I don't see a solution until building is automatic, because
>>>      we probably don't want to rebuild just to turn a successful RC into a
>>>      release.
>>
>> Automatic building (of installers / dmgs) won't solve it either. The
>> release would still have to be 'different' to the RC, and then it would
>> not be what we had tested.  We'd want to be 100% sure nothing had been
>> upgraded on the build machine between the RC being built and the release
>> build.
>>
>>
>> Instead I think our best option to providing status of a version is as
>> follows.
>>
>> Currently 'Check Version' passes a single parameter:
>> http://www.audacityteam.org/download/?from_ver=2.1.3
>>
>> It could pass more:
>> http://www.audacityteam.org/download/?from_ver=2.1.3&commitid=cf68891&sha256=b0fa790
>>
>>
>> This then needs a not very hard script on the server that matches the
>> versions and commit Ids.  The response page could then give a proper
>> identifier:
>> Audacity 2.1.3 RC1 of 10th-Jan-2017; Windows.
>>
>> With this approach we can change that designation later by changing the
>> information in the script.  If RC1 becomes our release, we can now make
>> that script say:
>> Audacity 2.1.3 Official Release; Windows.
>>
>>
>> So we ask users to click on 'check version', and tell us what they see.
>> We can also put the check version link in the about box too, if we want to.
>>
>> --James
>>
>>
>
> Interesting & +1.
>
> But that's different than what shows in the app, right?
>
> - V

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Distinguishing Releases, RCs, Nightlies.

Gale
Administrator
In reply to this post by Vaughan Johnson-4
On 13 February 2017 at 08:41, Vaughan Johnson <[hidden email]> wrote:

> On Fri, Feb 10, 2017 at 6:50 AM, James Crook <[hidden email]> wrote:
>> Gale wrote:
>>
>>> We have no way to indicate an RC is an RC inside the app such that the user
>>>      might know.
>
> Actually, we do.  We used to use it for betas.
>
> The code would have to be updated for each RC, of course, but it's a
> new build anyway.

Put another way, without rebuilding, we have no way to remove an
RC designation in the app to turn it into a release that does not show
RC designation.


Gale


>>>I don't see a solution until building is automatic, because
>>>      we probably don't want to rebuild just to turn a successful RC into a
>>>      release.
>>
>> Automatic building (of installers / dmgs) won't solve it either. The
>> release would still have to be 'different' to the RC, and then it would
>> not be what we had tested.  We'd want to be 100% sure nothing had been
>> upgraded on the build machine between the RC being built and the release
>> build.
>>
>>
>> Instead I think our best option to providing status of a version is as
>> follows.
>>
>> Currently 'Check Version' passes a single parameter:
>> http://www.audacityteam.org/download/?from_ver=2.1.3
>>
>> It could pass more:
>> http://www.audacityteam.org/download/?from_ver=2.1.3&commitid=cf68891&sha256=b0fa790
>>
>>
>> This then needs a not very hard script on the server that matches the
>> versions and commit Ids.  The response page could then give a proper
>> identifier:
>> Audacity 2.1.3 RC1 of 10th-Jan-2017; Windows.
>>
>> With this approach we can change that designation later by changing the
>> information in the script.  If RC1 becomes our release, we can now make
>> that script say:
>> Audacity 2.1.3 Official Release; Windows.
>>
>>
>> So we ask users to click on 'check version', and tell us what they see.
>> We can also put the check version link in the about box too, if we want to.
>>
>> --James
>>
>>
>
> Interesting & +1.
>
> But that's different than what shows in the app, right?
>
> - V
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Distinguishing Releases, RCs, Nightlies.

Gale
Administrator
In reply to this post by James Crook
Thanks, James. The tweak so the server script gets passed
commit ID and and SHA256 sounds good, though changing
the script according to which RC became release would
become another post-release task to remember to do.

However thinking about it I still like the idea of showing the
commit ID as "build <ID>" close by the Audacity version string
at the top of About Audacity. This makes it more likely we'll
know at once whether the user has the finalised release or
not, without having to ask specially.

It automatically means no different builds can say the same
version when opening "About".

It might not look quite so clean, but it is similar to the policy that
we don't provide different builds with the same file name.


Gale



On 10 February 2017 at 14:50, James Crook <[hidden email]> wrote:

> Gale wrote:
>
>> We have no way to indicate an RC is an RC inside the app such that the user
>>      might know. I don't see a solution until building is automatic, because
>>      we probably don't want to rebuild just to turn a successful RC into a
>>      release.
>
> Automatic building (of installers / dmgs) won't solve it either. The
> release would still have to be 'different' to the RC, and then it would
> not be what we had tested.  We'd want to be 100% sure nothing had been
> upgraded on the build machine between the RC being built and the release
> build.
>
>
> Instead I think our best option to providing status of a version is as
> follows.
>
> Currently 'Check Version' passes a single parameter:
> http://www.audacityteam.org/download/?from_ver=2.1.3
>
> It could pass more:
> http://www.audacityteam.org/download/?from_ver=2.1.3&commitid=cf68891&sha256=b0fa790
>
>
> This then needs a not very hard script on the server that matches the
> versions and commit Ids.  The response page could then give a proper
> identifier:
> Audacity 2.1.3 RC1 of 10th-Jan-2017; Windows.
>
> With this approach we can change that designation later by changing the
> information in the script.  If RC1 becomes our release, we can now make
> that script say:
> Audacity 2.1.3 Official Release; Windows.
>
>
> So we ask users to click on 'check version', and tell us what they see.
> We can also put the check version link in the about box too, if we want to.
>
> --James
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Loading...