Sounds like a better solution is being formed.
Op 14/03/2016 om 9:12 schreef Wim Jongman:
Yes. Stable points to stable and nightly points to nightly.
Since there is only one release build there is no need to make a script. We change arduino.product, build the release and then change arduino.product again. It is even thinkable that the release is done manually from the command line.
This brings me to another point: *Git Flow*. Please see my separate thread about this.
On Mon, Mar 14, 2016 at 12:13 AM, Roberto Lo Giacco <rlogiacco@xxxxxxxxx <mailto:rlogiacco@xxxxxxxxx>> wrote:
What if, when renaming the nightly to stable, we also replace the
update site with the stable URL? We can have a simple bash script
for it... it's a search & replace in an XML file, right? This way
all stables point to stable update site, while all nightly point
to nightly update site...
On Sun, Mar 13, 2016 at 11:37 PM, Jan Baeyens <jan@xxxxxxxxxx
<mailto:jan@xxxxxxxxxx>> wrote:
Thats what Wim and I say to.
My proposal is however "stretching this a bit"
My assumptions are:
The people who go for the stable will have a harder time
when "incidently" the nightly is activated then the people
who go for the nightly.
Where the people using the nightly will soon enough find
out that the nightly is inactive.
The more a release is ready the more likely it is we
advice "stable" people to go to the nightly. F.I. 2.3 did
not work on mac way before 2.4 was released.
We want to keep the steps for making a release as simple
and fail safe as possible.
Currently the release of a product is actually a renamed
nightly build. That is why all nightly builds are tagged as
3.0 eventhough 3.0 has not yet been released.
My proposal is to deacticvate the nightly when a release is
very mature. (so a bit to soon)
And activate the nightly again when the release is done. (just
on time)
This creates a small time window where we are inconsistent
with the rule but has the benefit of being able to upgrade a
build to release (read rename tar.gz).
Thinking of it. I'm not sure a standard update changes the
update sites.
My thinking
Jantje
Op 13/03/2016 om 23:08 schreef Roberto Lo Giacco:
May be we are saying the same thing using different words,
I'm not sure... What I am saying is those that download the
nightly should remain on the nightly update repo, those that
download the stable should always use the stable repo..
If that's the same thing then we are on the same line ;-)
On Sun, Mar 13, 2016 at 9:59 PM, Jan Baeyens <jan@xxxxxxxxxx
<mailto:jan@xxxxxxxxxx>> wrote:
Roberto
I think you say the same thing as I do.
So I don't understand why you advice against the approach.
Best regards
Jantje
Op 13/03/2016 om 21:39 schreef Roberto Lo Giacco:
I would advise against that approach: those having
downloaded the nightly should have the nightly repo set
as default, those downloading a stable should point to
the stable. If we deactivate the nightly those having a
nightly will receive an error... We want vast majority
of our users to use the stable, with few brave ones
using the nightly
On Sun, Mar 13, 2016 at 2:43 PM, Jan Baeyens
<jan@xxxxxxxxxx <mailto:jan@xxxxxxxxxx>> wrote:
I think that is a good idea. The easiest way I see
to implement this is as follows:
As soon as we come to a stabelized version we want
to release we set nightly to inactive.
As part of the post processing of a release we set
the nightly back to active.
The benefits I see is that when the release is
getting stable more and more "stable users" will get
advised to move to the nightly. Though they are
stable users.
We can still use any build to upgrade to release.
>I suggest to add the nightly repo to the product
for the nightly builds.
People that download the nightly are more likely to
also update from
nightly. When we build the release we have to set
nightly to inactive.
<a
href="https://www.freelists.org/list/eclipse-arduino-dev>eclipse-arduino-dev@xxxxxxxxxxxxx
<mailto:eclipse-arduino-dev@xxxxxxxxxxxxx></a>