Next release of Scala IDE?

[Alex Black]

Is there any chance of a updated release of the Scala IDE? I guess its
been about 7 months since the last release?

I'd love to see a release that doesn't have the deadlock/freeze issue
(among other things).

- Alex

[Matt Russell]

On Feb 9, 3:48 pm, Alex Black <a...@alexblack.ca> wrote:

> Is there any chance of a updated release of the Scala IDE? I guess its
> been about 7 months since the last release?

Not strictly speaking -- but there was a "not-a-release" last August:

http://www.scala-ide.org/2010/08/not-a-release-but-new-and-noteworthy-even-so/

If you want the latest and greatest, you'll want to follow either the
wip_experiment or the wip_exp_backport nightlies. It'd definitely be
nice to get to a releasable state soon, though!

-- Matt

[Jean-Philippe Pellet]

I had understood from this message of David's that he was going to
publish a release based on wip_exp_backport in the near future.

> Current version number of nightly is 1.0.0.<timestamp>, but after tomorrow
> version number will be 0.8.0.<timestamp>.
> Then you will have to uninstall the plugin, and reinstall. Sorry.
> Why ?
> Because, I would like to be able to publish release/immutable version. But
> the current quality of ScalaIDE is not "1.0.0", so to be able to
> intermediaire release. I decrease version number.
> The first release from wip_exp_backport is version 0.7.0 (the version
> produce by nightly build since one week).
> Currently the version is not yet available from "download.scala-ide.org" (I
> hope soon).
> You can use the following to use it :
> update-site : http://alchim31.free.fr/scala-ide/0.7.0/

[Miles Sabin]

On Wed, Feb 9, 2011 at 5:10 PM, Jean-Philippe Pellet <jppe...@gmail.com> wrote:
> I had understood from this message of David's that he was going to
> publish a release based on wip_exp_backport in the near future.

If David gives it a version number that's >= to the current version
number, then I'd be happy to publish a release right now ...

Cheers,

Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

[Donna Malayeri]

Miles,

I don't know enough about Eclipse: could you explain why the increasing version numbers is important?  Does it cause problems other than requiring an uninstall/reinstall?  

Donna

[Miles Sabin]

IMO that's more than enough of a problem. It means that anyone who is
currently following a nightly build won't be following it any more. It
also means that if they do uninstall and reinstall with a lower
version number and then update from a stale update site they'll be
downgraded to older release.

Version numbers should increase monotonically ... there are really no
exceptions to that rule.

[David Bernard]

Which version number ?

   release                           following nightly
1) 0.7.0                             0.8.0.<YYYYMMDDhhmm>

2) 1.0.0                             1.1.0.<YYYYMMDDhhmm>

3) 1.0.0.M<nn>                       1.0.0.<YYYYMMDDhhmm>
4) 1.0.0.<YYYYMMDDhhmm>-M<nn>        1.0.0.<YYYYMMDDhhmm>

5) other suggestions (may be include branch name, scala version or include it into the feature/category)

My comments (rules of choice) :

* release are immutable distribution (regardless) to quality

* on release channel (update-site) version should always increase

* on nightly channel (update-site) version should always increase

* qualifier are compared as alphanum so milestone number use 2 char : 00 -> 99

* should a user of release can upgrade to nighlty without need to uninstall ? if yes then 3 is not valid

* should 1.0.0 reserved for a "quality" statisfied version ? if yes then 2 is not valid

* should we use version rules of eclipse, osgi (having/using meaning of major, minor, bugfix) ? if yes then 3 and 4 are not good choice, because meaning is in qualifier part

* should current user of nightly, should not uninstall to install from future release channel ? if yes 1 is not valid (for user of master, helios, wip_experiment)

* should you prefer 0.14.0 or 1.0.0.<YYYYMMDDhhmm>-M14 ? (I prefer the first and ability to use bugfix part for quick fix release)

* switching "branch" will require uninstall, because branch will not "release" at same speed, and (nightly build are not timestamped synchronously)

* current user of nightly should uninstall/install when its last update is less usable (sometime it's the case)

* currently there is no channel for immutable/release, (and there is no release only nightly so technicaly speaking, there is no decrease of the version number on release channel (with choising 0.7.0) as there is no 1.0.0 or something else)

* I would like to have nightly that generate new update-site only when there is change (regardless of change in scalariform or scala-refactoring)

WDYT ?

Miles, what is the format of "new and ..." ? (html, markdown, textile, wiki page) I'll prepare it (need to browse changeset history)

Cheers,

/davidB

[Miles Sabin]

On Wed, Feb 9, 2011 at 9:23 PM, David Bernard
<david.be...@gmail.com> wrote:
> Which version number ?
>
>    release                           following nightly
> 1) 0.7.0                             0.8.0.<YYYYMMDDhhmm>
> 2) 1.0.0                             1.1.0.<YYYYMMDDhhmm>
> 3) 1.0.0.M<nn>                       1.0.0.<YYYYMMDDhhmm>
> 4) 1.0.0.<YYYYMMDDhhmm>-M<nn>        1.0.0.<YYYYMMDDhhmm>
> 5) other suggestions (may be include branch name, scala version or include
> it into the feature/category)

I think your option (4) is the one to go for (so that users can
upgrade from the milestone to a later nightly).

> Miles, what is the format of "new and ..." ? (html, markdown, textile, wiki
> page) I'll prepare it (need to browse changeset history)

Whatever is easiest for you ... any of those will be easy to get into
Wordpress. I'm assuming you've seen eclipse.org's "New and
Noteworthy"s ... if not you can find an example here,

http://goo.gl/wBMEe

[Alex Black]

> Not strictly speaking -- but there was a "not-a-release" last August:
>

>  http://www.scala-ide.org/2010/08/not-a-release-but-new-and-noteworthy...

I think thats the 7 months I was talking about.. maybe I'm off by a
month? Aug, Sept, Nov, Dec, Jan. ah, looks like I can't count. 5
months.

> If you want the latest and greatest, you'll want to follow either the
> wip_experiment or the wip_exp_backport nightlies. It'd definitely be
> nice to get to a releasable state soon, though!

I think I'm looking for the most stable, not necessarily latest and
greatest :)

[iulian dragos]

It seems to me that, if there will be a release really soon, it will
simply be a 'blessed' nightly. As with any blessing, it has a purely
symbolic value: it won't be more 'stable' nor in any way better than
the nightly before it. Therefore, I am against setting expectations by
using a version number like 1.0. This discussion took place a few days
ago on scala-ide-dev.

Instead, I propose to follow the release process of scalac, and issue
an RC ('blessed' nightly), wait for 1-2 weeks for feedback, fix the
eventual problems, and re-iterate. This means feature-freeze after RC,
only bugfixing. Hopefully this will also mean more testers and fewer
bugs. In the meantime, development can continue in the other branches.

As for wip_experiment (the branch based on scalac-trunk) I wouldn't
release it until 2.9. Next week the Scala team will probably release
2.9 RC1, and that is a good moment to release a beta (but we wouldn't
call it an RC, it's too early). We have a number of fixes and features
that we'd like to add in our branch before releasing this beta. It
would be good if we synchronized the two releases, but we need another
2 weeks at least, so please go ahead with wip_back_port if you feel
like it.

iulian

>
> -- Matt

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Jean-Philippe Pellet]

> It seems to me that, if there will be a release really soon, it will
> simply be a 'blessed' nightly. As with any blessing, it has a purely
> symbolic value: it won't be more 'stable' nor in any way better than
> the nightly before it.

I think it has more than symbolic value: some nightlies of the
wip_exp_backport branch are completely unusable, some others are
working great except for a few little things. Getting a blessed
nightly for 2.8.1 (even after 2.9 is out) would not sound like a bad
idea to me.

Cheers,
J.-P.

[David Bernard]

The goal of the "blessed" nightly or release it is to ease user to
choose "usable" version to go or to rollback (vs using timestamp +
archive).
I prefer downgrade version number choice 2 (as I did on
wip_exp_backport). But as I prefer more to spend energy and time to
work on the plugin, and as I 've got some waiting stacked stuff [1],
that can break the current plugin state (why I would like to provide a
checkpoint/milestone/release), I'll change the version follow 4) and
prepare version 1.0.0.<YYYYMMDDhhmm>-M01.

Miles, I re-read the previous "new and ..." and can I copy/paste a big
part, because there is no real new features, mainly improvement ?

/davidB

[1] basic text editor, merge of wip_experiment, support of 2.8.1 and
2.9-trunk (with common code but not common update-site, I not yet
found a solution), release notes

[Miles Sabin]

On Thu, Feb 10, 2011 at 8:10 PM, David Bernard
<david.be...@gmail.com> wrote:
> Miles, I re-read the previous "new and ..." and can I copy/paste a big
> part, because there is no real new features, mainly improvement ?

Yeah, that's fine ...

[Iulian Dragos]

On 2/10/11 9:10 PM, David Bernard wrote:
> The goal of the "blessed" nightly or release it is to ease user to
> choose "usable" version to go or to rollback (vs using timestamp +
> archive).
> I prefer downgrade version number choice 2 (as I did on
> wip_exp_backport). But as I prefer more to spend energy and time to
> work on the plugin, and as I 've got some waiting stacked stuff [1],
> that can break the current plugin state (why I would like to provide a
> checkpoint/milestone/release), I'll change the version follow 4) and
> prepare version 1.0.0.<YYYYMMDDhhmm>-M01.

If it's an issue of persistence of builds, can't we have hudson keep a
backlog of successful builds? Maybe with a voting plugin, similar to
what IntelliJ has for the Scala plugin nightly?

I'm fine with releasing milestones (weekly, or monthly), but I think
that any release that bears a number like 1.0 should have a release
process, going through several release candidates.

my 2 cents,
iulian

[Donna Malayeri]

There's no fancy voting plugin, but I have changed hudson (er,
jenkins) to keep the last 30 successful nightly builds.

Donna