Add Apache Royale nightly build download to Getting Started

[piotrzarzycki21]

@rat-moonshine this should be first priority adding Nightly Build for next release. Another user come to Moonshine and first thing which he did he download 0.9.4 SDK which is definitely outdated and had problem with building newest examples.

[piotrzarzycki21]

Issue has been moved from Moonshine repository. Following comment has been araised Moonshine-IDE/Moonshine-IDE#594 (comment)

[piotrzarzycki21]

Issue has been moved from Moonshine repository. Following comment has been araised prominic/Moonshine-IDE#594 (comment)

In my opinion there shouldn't be any new entrance on the list. Existing entrance should have radio button which indicates Nightly/Release version. Other framework may have also nightly builds, so in that way we will be prepared for adding nightly to them as well.

[piotrzarzycki21]

@rat-moonshine Is it working ? If it is how ? I don't see in your provided Installer 3.3.1 any option to download nightly build.

[rat-moonshine]

I don't think I had time to work on this yet, @piotrzarzycki21 .

[rat-moonshine]

Small updates on this:

• Variant toggle is now working fine and updates to whichever UI element it needs to be reflect
• Tested nightly build download works fine

At the end of download completion of nightly, I'm having one I/OError which I needs to investigate. Other than this, some CSS styling needs to be done to one of the element.

[rat-moonshine]

Download variants now introduced to SDK-Intaller. We can now declare multiple types of variant from this given list.

• Nightly variant introduced for Royale SDK download
• Nightly variant set as default-selected (we can change the default-selection when multiple variants)
• Downloads with only variant are not suppose to show variant-selection option
• Change between variants also affect to any UI element accordingly (i.e. size, total-size etc.)

Nightly build chose to download from following locations (without defining any build-number):
Windows: http://apacheroyaleci2.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/lastSuccessfulBuild/artifact/out/apache-royale-0.9.7-bin-js.zip
macOS: http://apacheroyaleci2.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/lastSuccessfulBuild/artifact/out/apache-royale-0.9.7-bin-js.tar.gz

[piotrzarzycki21]

@rat-moonshine Could email me and Adrian link to new installer ?

[rat-moonshine]

Sorry. I was in expression that the Bamboo plans also has a nightly deployable plan attached, which is not. I sent you an email to download links.

[piotrzarzycki21]

We need to finally have Nightly build for Installer!!!

[rat-moonshine]

We need to finally have Nightly build for Installer!!!

I meant deploy-somewhere-as-build on Bamboo, as we have for Moonshine.

[JoelProminic]

I did a test with this build. It seems to work, but after some discussion with @rat-moonshine, I found that this will only download the nightly build once - afterwards, it sees that the MoonshineSDKs/Royale_SDK/apache-royale-0.9.7-bin-js directory already exists, and reports that it is installed.

Thinking more about this, there are a couple use case details I want to clarify with @rat-moonshine and @piotrzarzycki21:

• Do we need to be able to download a new build every day? More than once a day? If so, we need Moonshine SDK Installer to have logic that will support the required frequency.
• Do we want to save old nightly builds? If so, we need to make it easier to distinguish them in the Moonshine SDK selector. If we want to automatically cleanup old nightly builds (say, 5), we'll need logic for this as well.
• Should the combobox default to the nightly or stable build? I think it should default to the stable build, so that we are confident it will work with our templates or new users. We could also have it change to the nightly build if the user has already downloaded the stable build.

If we need to re-download the nightly builds, we can use designs like these:

1. Always allow the user to download the latest nightly build again. This is the most powerful, but it doesn't give the user good feedback
2. Check a timestamp on the existing build and allow an install if it is a "new day". Note that with the time zone differences, the build time may be different for different users. I see that the last build was on "Jan 27, 2020 3:09:56 PM", but I don't have the time zone. If we use the exact build time, we should add some extra time for the build to run (say, 15 minutes)
3. Include the date or timestamp in the build directory name, so that we can save previous nightly builds. Otherwise, follow the same rules as in point 2

As for multiple nightly builds, currently the SDK selector looks like this. I can't easily tell which nightly build is with without expanding the width to see the full path. Adding a date in the description would help, but this label is currently read the descriptor file.

[piotrzarzycki21]

I was thinking about that as well today.

Do we need to be able to download a new build every day? More than once a day? If so, we need Moonshine SDK Installer to have logic that will support the required frequency.

In my opinion the answer is - yes we should allow user download Nightly build. However I don't think it should be based on some timestamp or any kind of mechanism. I would rather give to the user mechanism for removing Nightly build from disk drive.

Do we want to save old nightly builds? If so, we need to make it easier to distinguish them in the Moonshine SDK selector. If we want to automatically cleanup old nightly builds (say, 5), we'll need logic for this as well.

Having my opinion in mind - no automatic clean up - Let user decide whether he/she wanted to remove SDK.

Should the combobox default to the nightly or stable build? I think it should default to the stable build, so that we are confident it will work with our templates or new users. We could also have it change to the nightly build if the user has already downloaded the stable build.

It think it should point to stable version. It would be great to point to Nightly if stable is download if it's not so problematic to implement.

Always allow the user to download the latest nightly build again. This is the most powerful, but it doesn't give the user good feedback

I would like to avoid download and overwrite folder with sdk by new folder. Like I said I'm in favor of having some way in the UI where user can remove SDK from hard drive.

[rat-moonshine]

Okay. I did some updates, give a test if this suits to our needs.

• A re-download option now available for download-variant which provides by configuration XML
• The re-download option currently set for Royale Nightly only (I don't think we want this for any stable software, though)
• Having the option clicked, SDK-Installer deletes the existing directory first (this may takes longer as it'll delete file-systems asynchronously to get track for completion), this seems to be a needful step also as Apache SDK Installer expects the folder to be empty before an installation; And then attempt a re-download

Here's a visual when re-download option is available:

And when the installer attempts to delete the existing folder from file-system:

Here's the latest build for a test:
https://spaces.hightail.com/space/dhMpju9MTw

[piotrzarzycki21]

It looks like now something is broken. When I wanted to re-download Nightly - I got popup with Royale 0.9.6 - instead 0.9.7:

[rat-moonshine]

It looks like now something is broken. When I wanted to re-download Nightly - I got popup with Royale 0.9.6 - instead 0.9.7:

It seems like it's the license description only, which is general for both the variant types. If it is Okay, can we think about any general description value instead of mentioning version figure?

For the label in left-pane, I shall look into.

[piotrzarzycki21]

It seems like it's the license description only, which is general for both the variant types. If it is Okay, can we think about any general description value instead of mentioning version figure?

NO it's not the license. It downloads 0.9.6 SDK instead 0.9.7.

[rat-moonshine]

I confirm the break. Apparently it's turned out that I missed some crucial settlement before moving for the download. Thanks for the close observation @piotrzarzycki21 . This should be fixed now.

You can try by same download URL again, https://spaces.hightail.com/space/dhMpju9MTw.

One UI glitch to note - in "By Feature" section the label to the item squeeze when re-download option appears, expanding the application width however fix the problem for now. I will check this this sometime soon:

[piotrzarzycki21]

@JoelProminic could you please take a look into spelling of message when we deleting royale folder. It looks like that now:

[piotrzarzycki21]

I confirm the break. Apparently it's turned out that I missed some crucial settlement before moving for the download. Thanks for the close observation @piotrzarzycki21 . This should be fixed now.

You can try by same download URL again, https://spaces.hightail.com/space/dhMpju9MTw.

One UI glitch to note - in "By Feature" section the label to the item squeeze when re-download option appears, expanding the application width however fix the problem for now. I will check this this sometime soon:

Issue gone. I was able re download SDK 0.9.7 without the problem.

[JoelProminic]

@piotrzarzycki21, is this behavior good enough for your needs? This seems pretty simple and straightforward to me, but it doesn't have some of the control we were talking about earlier.

I would like to be able to see the date for the last nightly build. We could check the created or modified timestamp on one of the files, or I see a timestamp in the element of royale-asjs/flex-sdk-description.xml

<flex-sdk-description>
<name>Apache Royale 0.9.7 FP11.7 AIR14.0 en_US</name>
<version>4.14.1</version>
<build>20200128</build>
</flex-sdk-description>

A tooltip would probably be sufficient. Alternatively, we could display it in the UI, but shorten it down to the month and day (i.e. Jan 28), or just the year for builds older than a year, to keep the label compact.

[piotrzarzycki21]

@piotrzarzycki21, is this behavior good enough for your needs? This seems pretty simple and straightforward to me, but it doesn't have some of the control we were talking about earlier.

I would like to be able to see the date for the last nightly build. We could check the created or modified timestamp on one of the files, or I see a timestamp in the element of royale-asjs/flex-sdk-description.xml

<flex-sdk-description>
<name>Apache Royale 0.9.7 FP11.7 AIR14.0 en_US</name>
<version>4.14.1</version>
<build>20200128</build>
</flex-sdk-description>

A tooltip would probably be sufficient. Alternatively, we could display it in the UI, but shorten it down to the month and day (i.e. Jan 28), or just the year for builds older than a year, to keep the label compact.

Yeah, it is enough good. We can capture further improvements in the next tickets.

[rat-moonshine]

I think we can consider for a small space for a timestamp tooltip generation.

I have added a tooltip-link which shall display the creation-date value for the SDK folder. Note: This tooltip-link will available only in 'By Software', software-wise:

The displaying type is locale date/time-string.

[piotrzarzycki21]

Could you provide newest installer, cause I see you have made some updates. I think we are enough good to have it close - Aren't we ?

[JoelProminic]

Rather than display the "Created On" link with a tool tip, I think we should just display "Installed ". If the full timestamp won't fit in the UI, then you can abbreviate it (i.e. Jan 29, 2020 or just Jan 29) and show the full timestamp in a tooltip. The date should be sufficient for the display, but some power users like Piotr may need to see the full time.

If you can do it easily, add the timestamp to the "installed" icon as well.

[rat-moonshine]

Previous tooltip-link replaced with static label: "Installed: Jan 26, 2020". The label also accompany with full-date/time locale string.

In "By Feature" section the said tooltip accompany with the downloaded-tick icon.

[piotrzarzycki21]

Could you also place that tooltip over download icon in "By Softwer" ?

[rat-moonshine]

Could you also place that tooltip over download icon in "By Softwer" ?

I thought about that, but it'd be redundant. Either we choose over date-label or installed-icon. Perhaps, over installed icon only would keep things similar between "By Feature" (?)

[piotrzarzycki21]

I thought about that, but it'd be redundant. Either we choose over date-label or installed-icon. Perhaps, over installed icon only would keep things similar between "By Feature" (?)

When I'm going to Installer I won't roll over "Installed..." world - I wouldn't even think about that, so user wouldn't as well. You will have your mouse cursor more often in the area of download icon. Even more when you roll over download icon this tooltip should say "Installed full date" - cause I wouldn't know what is all about - If I see only date.

[rat-moonshine]

That seems also fits my earlier thought on keeping similarity. I shall move the tooltip to installed icon then with pre-text 'Installed'.

[rat-moonshine]

You can test latest builds from https://spaces.hightail.com/space/dhMpju9MTw using the above changes and the break reported by @piotrzarzycki21 recently where Gradle download URL failing (fixed).

[piotrzarzycki21]

You can test latest builds from https://spaces.hightail.com/space/dhMpju9MTw using the above changes and the break reported by @piotrzarzycki21 recently where Gradle download URL failing (fixed).

Gradle download is working. I think we are done with that issue. Close it.

[piotrzarzycki21]

It's been tested so I'm closing it.