branch/build/update-site change request
David Bernard
I continue in the spirit of my previous emails to "reorg" branch,
version, update-site...
Can you :
1. replace the "copy update-site url" from http://scala-ide.org by a
simple "Download" with a link to http://download.scala-ide.org/
2. rename wip_exp_backport to 1.x.y_wip
2.1. rename branch wip_exp_backport to 1.x.y_wip
2.2. create the update-site scala-2.8.1/update-1.x.y_wip
2.3. rename in hudson/jenkins, the job, the branch used, the target
update-site location
2.4. redirect "permantly"
http://download.scala-ide.org/nightly-update-wip-exp-backport-2.8.1.final/
to http://download.scala-ide.org/scala-2.8.1/update-1.x.y_wip/
2.5. update the url on the download page
3. rename milestones to 1.x.y_staging
3.1. rename branch milestones to 1.x.y_staging
3.2. create the update-site scala-2.8.1/update-1.x.y_staging
3.3. rename in hudson/jenkins, the job, the branch used, the target
update-site location
3.4. redirect "permantly" to
http://download.scala-ide.org/scala-2.8.1/update-1.x.y_staging/
* http://download.scala-ide.org/nightly-update-master-2.8.1.final/
* http://download.scala-ide.org/nightly-update-helios-2.8.1.final/
* http://download.scala-ide.org/update-current-35
3.5. add the url of the update-site on the download page
4. change nightly build script of 1.x.y_wip to use same script as from
milestone/1.x.y_staging that include (branch name in qualifier)
5. suspend/disable nightly build of no longer used update-site (master, helios)
6. rename + close deprecated branches
6.1. master -> deprecated_e35
6.2. helios -> deprecated_e36
Next I'll create the branch 1.x.y (for solid, validated version).
(that will require its own nightly build and update-site)
Thanks.
/davidB
PS : how can I update download page, hudson myself ?
PS : how can I help ?
David Bernard
rename in the ticket system (I don't have permission) :
* version 1.0.0-SNAPSHOT to 1.x.y if possible
On 6 avr, 13:16, David Bernard <david.bernard...@gmail.com> wrote:
> Hi Miles, (or anybody with the permissions)
>
> I continue in the spirit of my previous emails to "reorg" branch,
> version, update-site...
>
> Can you :
> simple "Download" with a link tohttp://download.scala-ide.org/
> 2.1. rename branch wip_exp_backport to 1.x.y_wip
> 2.2. create the update-site scala-2.8.1/update-1.x.y_wip
> 2.3. rename in hudson/jenkins, the job, the branch used, the target
> update-site location
> tohttp://download.scala-ide.org/scala-2.8.1/update-1.x.y_wip/
> 3. rename milestones to 1.x.y_staging
> 3.1. rename branch milestones to 1.x.y_staging
> 3.2. create the update-site scala-2.8.1/update-1.x.y_staging
> 3.3. rename in hudson/jenkins, the job, the branch used, the target
> update-site location
> * http://download.scala-ide.org/nightly-update-helios-2.8.1.final/
Miles Sabin
<david.be...@gmail.com> wrote:
> Hi Miles, (or anybody with the permissions)
>
> I continue in the spirit of my previous emails to "reorg" branch,
> version, update-site...
I think that's a bit over complicated.
I propose pointing the "Copy update site URL" widget on scala-ide.org
at the wip_exp_backport update site: the widget is already pointing at
a nightly build, albeit a stale one, and the wip-exp_backport update
site is now the "Recommended for most users" update site on
download.scala-ide.org.
Renaming branches in git doesn't really solve any immediate problems,
and just makes work for everybody. I think it would be best to leave
any major reorganization until you're ready to merge with
wip_experiment.
Cheers,
Miles
--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin
Miles Sabin
> I propose pointing the "Copy update site URL" widget on scala-ide.org
> at the wip_exp_backport update site: the widget is already pointing at
> a nightly build, albeit a stale one, and the wip-exp_backport update
> site is now the "Recommended for most users" update site on
> download.scala-ide.org.
In fact I'd like to do that today ... it doesn't make sense to have
any more users install the older version.
David Bernard
From: David Bernard <david.be...@gmail.com>
Date: Wed, Apr 6, 2011 at 13:58
Subject: Re: [scala-ide-dev] branch/build/update-site change request
To: Miles Sabin <mi...@milessabin.com>
I really would like to have at least 2 branches + update-site
available to end-users.
Simply because I don't want users to use the blending edge of wip
where we can broke the behavior
(eg after a merge from wip_experiment I need at least few day of usage
to identify some break,...)
I highly prefer that the default update-site for (new) user to be
staging one, lot of less risky (and bad experience)
I'm ok to setup the full stuff if you grant me access.
/davidB
David Bernard
* I test on real project at work where I don't have the source,... and
use the update-site
* some broke can appear only on hudson build, eg the append of -null
after the last merge from wip_experiment, because build script are not
the same between both CI.
/davidB
iulian dragos
On Wed, Apr 6, 2011 at 12:16 PM, David BernardI think that's a bit over complicated.
<david.be...@gmail.com> wrote:
> Hi Miles, (or anybody with the permissions)
>
> I continue in the spirit of my previous emails to "reorg" branch,
> version, update-site...
I propose pointing the "Copy update site URL" widget on scala-ide.org
at the wip_exp_backport update site: the widget is already pointing at
a nightly build, albeit a stale one, and the wip-exp_backport update
site is now the "Recommended for most users" update site on
download.scala-ide.org.
Renaming branches in git doesn't really solve any immediate problems,
and just makes work for everybody. I think it would be best to leave
any major reorganization until you're ready to merge with
wip_experiment.
Cheers,
Miles
--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
David Bernard
* I can NOT recommand "wip_exp_backport" to user !!
* It will avoid to contribution to master.
* It's a refactor, rename iteam to refect content/action/...
* It impact mainly myself
I'm ok to do the work, but I don't have the permissions (I can setup
an other CI (like ScalaSolutions did)).
We don't know when "merge" will be. It's now 3 month ago, when I
request the rename for the first time.
/davidB
Miles Sabin
<david.be...@gmail.com> wrote:
> I highly prefer that the default update-site for (new) user to be
> staging one, lot of less risky (and bad experience)
> I'm ok to setup the full stuff if you grant me access.
OK, that's fine. We have the milestones branch for this, right? Is it
up to date? In which case I can kick off a build and point the front
page at it.
David Bernard
Let's go with milestones (bad name).
You can already put it on download page (with a note that indicate
quality at "staging".
You don't have to kick off. only link the update-site (generated by CI)
Don't include version in the update-site (like beta1 or M01), because
future version will be committed/pushed into this branch.
/davidB
Miles Sabin
<david.be...@gmail.com> wrote:
> OK, until I convince you about "renaming" (when you'll come to France ;-) ).
:-)
> Let's go with milestones (bad name).
> You can already put it on download page (with a note that indicate
> quality at "staging".
>
> You don't have to kick off. only link the update-site (generated by CI)
> Don't include version in the update-site (like beta1 or M01), because
> future version will be committed/pushed into this branch.
OK, that sounds perfect ... thanks :-)
Miles Sabin
> On Wed, Apr 6, 2011 at 9:04 PM, David Bernard
>> Don't include version in the update-site (like beta1 or M01), because
>> future version will be committed/pushed into this branch.
>
> OK, that sounds perfect ... thanks :-)
Done ...
David, let me know if you have a blog post that you'd like to post on
scala-ide.org to go with this.
David Bernard
About "copy update-site url" I notice you change the url behind, but
(IMHO) a link to the download page (and not in the text) should be
better.
I must admit that I don't like the button, it is not "obvious" : user
need to enable flash (I have flashblock), there no cursor change on
over, nor animation on click.
/davidB (never happy ;-) )
Miles Sabin
<david.be...@gmail.com> wrote:
> About "copy update-site url" I notice you change the url behind, but
> (IMHO) a link to the download page (and not in the text) should be
> better.
> I must admit that I don't like the button, it is not "obvious" : user
> need to enable flash (I have flashblock), there no cursor change on
> over, nor animation on click.
We could change the widget to be the same one as is used on the
downloads page. But we should keep using a widget of some sort: if
it's a navigable link then people will navigate through it in their
browser rather than copying and pasting it into Eclipse ... that used
to be an endless source of complaints previously.