Ramping up for a release
iulian dragos
The Scala project is getting ready for the 2.9 release, and a release
candidate should be out tomorrow or Monday. I think this is a great
opportunity for the Eclipse plugin to release a beta version!
I believe the wip_experiment branch is in good shape for a beta
release, and probably the backport is the same (David, please
confirm). I propose we release a 1.0-beta1 for both 2.9-RC1 and for
2.8.1 (based on wip_exp_backport) on the same day with the Scala
release (or one day later, depending on how well we can synchronize).
The downloads page should be reorganized to put the 2.9 and 2.8
(backport) first, in the Releases section, followed by the nightlies.
For the nightlies, we should only keep the 2.9 and 2.8 (backport)
since the others are unsupported. Unsupported means that any bug that
appears in those versions and can't be reproduced in
wip_experiment/backport is not going to be fixed, and there won't be
any new release targeting those compilers. I already got confirmation
with Miles that he can assist us with the downloads page.
Once the beta is out, we should enter a bug-fixing phase, where we
don't add new features. I will create milestones for 1.0 (the next
final release) and 1.1 (next feature release), plus a Backlog. All
current tickets will go in Backlog. This may sound a bit harsh, but
the current number of open tickets is unmanageable, and we need some
focus. By having milestones, we all know where we're heading and how
far we are from the next milestone. In the short and medium term, we
will all have to go through the backlog and move tickets that make
sense to one of the milestones, or close them -- Backlog is perfectly
valid as a container of tickets, but it should have only those that
actually make sense. I hope that other people in the community will
help us sort out the pile of tickets (I also hope many of them are
invalid now) by closing those that can't be reproduced in one of the
two branches.
The next thing we should talk about is the branch reorganization. We
should rename wip_experiment and wip_exp_backport to better reflect
their prominent status, and do the same to master/helios. But that's
another discussion.
For the release version, I propose to have 1.0.0.beta1 (there may be
more than one beta).
What do you think?
iulian
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
Miles Sabin
> What do you think?
All sounds good to me ...
Cheers,
Miles
--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin
David Bernard
ijuma
Quality and content of wip_exp_backport and wip_experiment are too different (like you show the Features page) to share the same version/backlog/... IMO we should have 2 "editions" until real merge (post 1.0) or not "release" what is in wip_exp_backport as 1.0 but only as milestones (like I try to do since 2 months).
Matt Russell
> > What do you think?
>
> All sounds good to me ...
-- Matt
David Bernard
iulian dragos
I think there is a confusion, David was talking about
tickets/milestones (at least, that's what I understand). Regarding
version numbers, we'll have two different update sites and different
qualifiers. Giving them different version numbers would mean one being
ahead of the other, and as you noticed, there is no clear update path.
But I don't have a huge problem with putting different version
numbers, I just don't know what hey should be. What do you think
should be their version numbers?
At any rate, I think the biggest difference is the compiler that comes
with each, and I expect that to play the biggest role in choosing one
over the other. The other features are not that different, IMO the
only feature absent in wip_experiment is integration of gsoc
(https://www.assembla.com/wiki/show/scala-ide/Features), tuning and
simple editors being mostly work in progress or debugging options for
developers.
The reason I'd like to see both versions released at the same time is
that the default one (based on 2.8.1) is clearly worse than any of the
two. We get a constant stream of tickets that we don't know what to do
with, because users install the (de facto) unsupported versions. We
also cannot put 2.9 as the default download option until 2.9 is the
final release of Scala, so we need to offer an alternative for 2.8,
and that's wip_exp_backport.
cheers,
iulian
> Best,
> Ismael
iulian dragos
<david.be...@gmail.com> wrote:
>> For the release version, I propose to have 1.0.0.beta1 (there may be
>> more than one beta).
>>
>> What do you think?
>
> Like every time, I've got complain (I'm French ;-) )
> Why beta(s), then milestone(s), then final ?
> Why not milestone(s) then final ?
Ok, I proposed beta because we don't really have a release candidate
(some tickets should still be fixed for a 1.0 release, in my opinion).
I don't know exactly what is the meaning of milestone, but as long as
that is similar in intention to a beta, we can call it as such.
> About version number, like I already ask/tell in other Thread timestamp
> should be included as first part of the qualifier for every distributed
> plugin (I know, I'm repeat myself).
> http://groups.google.com/group/scala-ide-user/browse_thread/thread/1d3fcf66d01040c8/062e16c9b660bcc3?lnk=gst&q=next+release#062e16c9b660bcc3
I answered on the other thread and I think you're right.
> More I thought and study version numbering, less I like the politic to use
> suffix like beta, RC, final/GA.
> Eg if there is no bug in RC then it become the final but changing the suffix
> and rebuild imply that last RC (validated) != final
> And in this case what is the purpose to have bug fix in the version number ?
I actually like having a suffix (like M01/02) because that's way
easier to read/understand by users than a date like 20110417 or
20110322. Can you quickly tell which one is the newest?
I don't see why the bugfix part is not useful anymore (at least, it's
not more useless than with any other qualifier scheme, unless I'm
missing something). If we go down that route, we can use only
timestamps as version numbers :) I would say, let's have a suffix,
even for the slight inconvenience of having two versions (last RC and
final) with different versions but identical content. That will make
it way easier for users to know if they're on a stable build or not.
> If you reply because every body know that there are always bug then what is
> the purpose to have RC steps (as RC and bug fix are made on the same
> "freezed" process?
I think a stable version simply lives longer than an RC. You won't
write blogposts about RCs, but you may write about releases (even
bugfix releases).
> Else, what is currently in wip_exp_backport is not "ready" for users, but
> what is in the "milestones" branch is. I'll not have time before Monday to
> merge/adapt from wip_experiment into wip_exp_backport and time to test (from
> me and users).
Sorry for being so short-notice, I got word of the 2.9 RC only yesterday.
> Quality and content of wip_exp_backport and wip_experiment are too different
> (like you show the Features page) to share the same version/backlog/... IMO
> we should have 2 "editions" until real merge (post 1.0) or not "release"
> what is in wip_exp_backport as 1.0 but only as milestones (like I try to do
> since 2 months).
That's perfectly fine with me, I leave that up to you to decide.
However, I'd really like to have both the 2.9 and 2.8 backport
milestones featured above the 'stable' 2.8.1, because we need to
divert users away from these (practically) unsupported versions.
> branches suggestion
> * 1.0.x_scala2.9.0 from where release 1.0.x 'll done and maintained
> * master_scala2.9.0 where you can continue dev for next (1.1, ....) : new
> name of wip_experiment
> * master_scala2.8.1 where we can continue dev (backport, patch,...) : new
> name of wip_exp_backport
> Each master has it's nightly build + update-site
> I would like to keep the milestones channel (to rename
> milestones_scala2.8.1)
> channel = branch + CI + update-site
I agree. Let's do this change once we have a milestone release.
> Work of Martin about backport compiler 2.9.0 into 2.8.2 can be done in a
> branch from master_scala2.9.0.
> I hope, I wasn't too aggressive or negative (I've lot of difficulty to
> nuance/round my sentences in English)
Don't worry, English is not my native language either. Thanks for all
your work and feedback! Without your work, we wouldn't have any
alternative for 2.8!
thanks,
iulian
ijuma
At any rate, I think the biggest difference is the compiler that comes
with each, and I expect that to play the biggest role in choosing one
over the other. The other features are not that different, IMO the
only feature absent in wip_experiment is integration of gsoc
(https://www.assembla.com/wiki/show/scala-ide/Features), tuning and
simple editors being mostly work in progress or debugging options for
developers.
The reason I'd like to see both versions released at the same time is
that the default one (based on 2.8.1) is clearly worse than any of the
two. We get a constant stream of tickets that we don't know what to do
with, because users install the (de facto) unsupported versions. We
also cannot put 2.9 as the default download option until 2.9 is the
final release of Scala, so we need to offer an alternative for 2.8,
and that's wip_exp_backport.
David Bernard
I think there is a confusion, David was talking aboutOn Fri, Mar 25, 2011 at 8:55 AM, ijuma <ism...@juma.me.uk> wrote:
> Hey all,
> It's great to see progress being made towards a release.
> On Thursday, March 24, 2011 9:13:40 PM UTC, David Bernard wrote:
>>
>> Quality and content of wip_exp_backport and wip_experiment are too
>> different (like you show the Features page) to share the same
>> version/backlog/... IMO we should have 2 "editions" until real merge (post
>> 1.0) or not "release" what is in wip_exp_backport as 1.0 but only as
>> milestones (like I try to do since 2 months).
>
> I agree with David that the two branches have enough differences that it
> would be confusing to release them both with the same version. It's
> particularly confusing because the one based on 2.9.0 would have less
> features than the one based on 2.8.1.
tickets/milestones (at least, that's what I understand).
Regarding
version numbers, we'll have two different update sites and different
qualifiers. Giving them different version numbers would mean one being
ahead of the other, and as you noticed, there is no clear update path.
But I don't have a huge problem with putting different version
numbers, I just don't know what hey should be. What do you think
should be their version numbers?
At any rate, I think the biggest difference is the compiler that comes
with each, and I expect that to play the biggest role in choosing one
over the other. The other features are not that different, IMO the
only feature absent in wip_experiment is integration of gsoc
(https://www.assembla.com/wiki/show/scala-ide/Features), tuning and
simple editors being mostly work in progress or debugging options for
developers.
The reason I'd like to see both versions released at the same time is
that the default one (based on 2.8.1) is clearly worse than any of the
two. We get a constant stream of tickets that we don't know what to do
with, because users install the (de facto) unsupported versions. We
also cannot put 2.9 as the default download option until 2.9 is the
final release of Scala, so we need to offer an alternative for 2.8,
and that's wip_exp_backport.
iulian dragos
> On Friday, March 25, 2011 10:08:05 AM UTC, Iulian Dragos wrote:
>>
>> At any rate, I think the biggest difference is the compiler that comes
>> with each, and I expect that to play the biggest role in choosing one
>> over the other. The other features are not that different, IMO the
>> only feature absent in wip_experiment is integration of gsoc
>> (https://www.assembla.com/wiki/show/scala-ide/Features), tuning and
>> simple editors being mostly work in progress or debugging options for
>> developers.
>
> OK, fair enough if you believe the experiences to be similar in both
> versions.
I was only pointing out the missing features in 2.9. If we talk about
the "experience", it's hard for me to compare: I tried out
wip_exp_backport only for an afternoon, and it seemed ok. I am quite
convinced that 2.9 is better in what regards stability (not all fixes
in wip_experiment were back-ported), but it's definitely better than
the 2.8.1 version.
> I suggest linking to the Features page from the announcement. I
> still think it will cause some confusion that the version for 2.8.1 has
> features that the version for 2.9.0 does not. And it's still unclear to me
> why those features will be in the version for 2.8.1 if they are not believed
> to be stable enough for 2.9.0 at this point.
That's David's work, so I think he should answer this question. I'd
just like to point out that without his work, there would be no
alternative for 2.8 -- and what is in or out of backport is his
decision. Point taken, we should explain very well what each version
offers.
> Maybe the reason is simply that
> it's the state of the codebase right now.
Indeed. But realistically speaking, we are talking only about the
integration of the Google summer of code project (highlight implicit
applications). The reason why this is not in 2.9 is mostly because we
are not sure we can have it fast enough (it requires full type
checking.. can we do that fast enough for each keystroke?).
>>
>> The reason I'd like to see both versions released at the same time is
>> that the default one (based on 2.8.1) is clearly worse than any of the
>> two. We get a constant stream of tickets that we don't know what to do
>> with, because users install the (de facto) unsupported versions. We
>> also cannot put 2.9 as the default download option until 2.9 is the
>> final release of Scala, so we need to offer an alternative for 2.8,
>> and that's wip_exp_backport.
>
> Hopefully both branches are now stable enough that no negative publicity
> will be generated by users that try it with increased expectations.
I agree this is a big concern. It's a beta release, and I can say for
wip_experiment: we are all using it for the Scala compiler (80k lines
of code) every day now. I'm not saying there are no bugs, or that
everything works (mixed Java-Scala projects are one area where I don't
know how well it will work). I'm just saying it's a totally different
experience from half a year ago.
We need to release in order to get feedback and improve it further. In
the current state, we get tickets for 2.8.1 and which have been fixed
long ago in one of these branches, and we already get (tons of)
negative publicity. Releasing a milestone/beta will direct users
towards the better experience, and get us useful bug reports. Just to
give an idea, every day we have about 500 downloads for 2.8.0 and
2.8.1 combined. backport and exp_experiment get about 30-40 each.
To summarize, you suggest that we wait and merge the two branches
before a release? Or that the current state is not good enough for a
release?
David Bernard
I don't see why the bugfix part is not useful anymore (at least, it's
not more useless than with any other qualifier scheme, unless I'm
missing something). If we go down that route, we can use only
timestamps as version numbers :) I would say, let's have a suffix,
even for the slight inconvenience of having two versions (last RC and
final) with different versions but identical content. That will make
it way easier for users to know if they're on a stable build or not.
I think a stable version simply lives longer than an RC. You won't
> If you reply because every body know that there are always bug then what is
> the purpose to have RC steps (as RC and bug fix are made on the same
> "freezed" process?
write blogposts about RCs, but you may write about releases (even
bugfix releases).
> Else, what is currently in wip_exp_backport is not "ready" for users, butSorry for being so short-notice, I got word of the 2.9 RC only yesterday.
> what is in the "milestones" branch is. I'll not have time before Monday to
> merge/adapt from wip_experiment into wip_exp_backport and time to test (from
> me and users).
> Quality and content of wip_exp_backport and wip_experiment are too differentThat's perfectly fine with me, I leave that up to you to decide.
> (like you show the Features page) to share the same version/backlog/... IMO
> we should have 2 "editions" until real merge (post 1.0) or not "release"
> what is in wip_exp_backport as 1.0 but only as milestones (like I try to do
> since 2 months).
However, I'd really like to have both the 2.9 and 2.8 backport
milestones featured above the 'stable' 2.8.1, because we need to
divert users away from these (practically) unsupported versions.
iulian dragos
<david.be...@gmail.com> wrote:
>> I think there is a confusion, David was talking about
>> tickets/milestones (at least, that's what I understand).
>
> No I talk about release (channel), for me assembla tickets/milestones should
> mirror release, announce and version number of existing.
Sorry for that.
>>
>> Regarding
>> version numbers, we'll have two different update sites and different
>> qualifiers. Giving them different version numbers would mean one being
>> ahead of the other, and as you noticed, there is no clear update path.
>> But I don't have a huge problem with putting different version
>> numbers, I just don't know what hey should be. What do you think
>> should be their version numbers?
>
> Same issue. It depends a lot of the plan for futur (merge of branches,...)
There should definitely be only one development branch, and many
feature branches, following the git-flow model.
>> The reason I'd like to see both versions released at the same time is
>> that the default one (based on 2.8.1) is clearly worse than any of the
>> two. We get a constant stream of tickets that we don't know what to do
>> with, because users install the (de facto) unsupported versions. We
>> also cannot put 2.9 as the default download option until 2.9 is the
>> final release of Scala, so we need to offer an alternative for 2.8,
>> and that's wip_exp_backport.
>
> I agree about the problems, not about the solutions.
> I tried to setup the milestones channel to fix the probleme for 2.8 users,
> until there is a better solution.
Can you please be more explicit? I agree that having milestones is a
good thing. If you think back_port is not in enough good shape, then I
agree it's better to wait. So we agree to have different schedules for
the two branches?
iulian
> /davidB
iulian dragos
<david.be...@gmail.com> wrote:
>>
>> I don't see why the bugfix part is not useful anymore (at least, it's
>> not more useless than with any other qualifier scheme, unless I'm
>> missing something). If we go down that route, we can use only
>> timestamps as version numbers :) I would say, let's have a suffix,
>> even for the slight inconvenience of having two versions (last RC and
>> final) with different versions but identical content. That will make
>> it way easier for users to know if they're on a stable build or not.
>
> what is the more clear and what is the change in the workflow between :
> 1.0.0-RC1 1.0.0
> 1.0.0-RC2 1.0.1
> 1.0.0-RC3 1.0.2
> 1.0.0 1.0.3
> 1.0.1 1.0.4
> 1.0.2 1.0.5
> Now I need to think with the inclusion of timestamp ;-)
Ok, I'm almost convinced :-). 1.0.0 is such a round number, that I am
afraid of the 'broken expectations' that Ismael mentioned. So if we
follow the milestones that you mentioned, it would be
1.0.0.20110325-branch-M01
1.0.0.20110326-branch-M02
1.0.0.20110327-branch-M03
1.0.0.20110328-branch
1.0.1.20110329-branch
1.0.2.20110330-branch
?
and for nightlies
1.1.0.20110330-branch
1.1.0.20110331-branch
etc?
thanks,
iulian
David Bernard
That's David's work, so I think he should answer this question. I'd
just like to point out that without his work, there would be no
alternative for 2.8 -- and what is in or out of backport is his
decision. Point taken, we should explain very well what each version
offers.
David Bernard
So we agree to have different schedules for
the two branches?
Ruediger Keller
I'm following this discussion somewhat and just wanted to add some
thoughts of mine.
Regarding the version schemes, there seems to be quite some
uncertainty regarding the expectations set by the various naming
schemes. I will therefore try to explain what I think are the most
commonly used schemes and the associated expectations.
Using a "round" version like 1.0.0 suggests a feature complete, tested
and bug free "final" version. So this creates really high expectations
and I wouldn't use it lightly.
Calling something a milestone means that you finished some but not all
of the planned features for the final version, and that it is in a
state where it can be used to some extends, in contrast to a nightly
build which may just be broken completely. It's like saying: early
adopters, here is something to try at your own risk. Usually bigger
projects like Eclipse use this scheme, when using milestones for the
internal project planning. I'm not really sure if using milestone
builds is appropriate for the Scala Eclipse plugin. Do you plan using
milestones internally? Milestones have the added disadvantage that
outsiders have no clue what a milestone represents and what to expect
from it, unless you publish you milestone plans and the associated
goals.
Calling something a Beta means that you are usually feature complete
or at least all major features are complete. Also, it is usually
expected to be mostly usable, but there are probably bugs left. When
using milestones, you usually begin releasing betas after the last
milestone, i.e. when all features are complete and you want to start
concentrating on fixing bugs. I guess not all projects using
milestones use the beta scheme, but doing it sends a clear message to
early adopters: we are (mostly) feature complete and expect it to be
usable, so please help us finding bugs.
Calling something a Release Candidate means to you are feature
complete and you are confident that there are no bugs left. I.e. you
expect that you could just put the label "final" on the release and be
done. This sets quite high expectations and should definitely not be
the first publicly available release if you don't have huge internal
testing resources or closed betas with many participants. It would
just set false expectations. This is also the reason why I don't like
the Scala team to release RCs as the first thing when there hasn't
been any broader testing. Scala 2.8 going through something like 7 RCs
is clearly an indication that these should have been called betas, not
RCs.
Calling something final is just that. It's complete, tested and bug
free and ready for public consumption.
I think it would be most fitting for the Scala plugin to only use the
beta scheme, for simplicity's sake. The first release could be a
1.0.0.Beta1 (+ prefixes and suffixes if you like). Continue releasing
betas as long as you think it's necessary to get the plugin stable.
You can throw in RCs at the end, if you want, but going just with
betas until it's final would be fine, too. The last beta/RC that
proves to be stable would be relabeled as final and you can begin work
on version 2.0.0.
Regarding the GSoC feature "show implicits", when I first heard about
it, I thought it would be super great. But when it finally arrived at
wip_exp_backport it didn't take long for me to disable it. In practice
it mostly seems to distract with it squiggly lines all over the place
and also it interferes badly with the error markers. I wouldn't mind
it being absent from the plugin, at least until it's significantly
improved.
Regards,
Rüdiger
2011/3/25 iulian dragos <jagu...@gmail.com>:
iulian dragos
Thank you for the very good summary! I agree with everything above,
and my personal choice would be a beta1, as in the beginning of this
thread. However, I think there's value in having a uniform versioning
scheme among branches, so let's see what David thinks.
> Regarding the GSoC feature "show implicits", when I first heard about
> it, I thought it would be super great. But when it finally arrived at
> wip_exp_backport it didn't take long for me to disable it.
I had the same experience, but the reason I'd wait for inclusion is
mostly related to (uncertainty of) its performance.
cheers,
iulian
Matt Russell
> I had the same experience, but the reason I'd wait for inclusion is
> mostly related to (uncertainty of) its performance.
> The reason why this is not in 2.9 is mostly because we
> are not sure we can have it fast enough (it requires full type
> checking.. can we do that fast enough for each keystroke?).
instantaneously. It's pretty much the same deal as mark occurrences
(which is in wip_experiment), I would have thought.
-- Matt
Matt Russell
> Regarding the GSoC feature "show implicits", when I first heard about
> it, I thought it would be super great. But when it finally arrived at
> wip_exp_backport it didn't take long for me to disable it. In practice
> it mostly seems to distract with it squiggly lines all over the place
> and also it interferes badly with the error markers. I wouldn't mind
> it being absent from the plugin, at least until it's significantly
> improved.
an entry in the toolbar which lets you turn it on and off quickly;
perhaps we could add an entry for this too? I would find Show
Implicits to be more useful if I could quickly turn it on for a short
implicit-debug session, before switching it back off again.
-- Matt
Eugene Vigdorchik
Mark occurrences runs as an Eclipse job, i.e. asynchronously.
For other actions that provide highlighting upon a type-check finish I
think the presentation compiler should provide a callback interface.
Eugene.
>
> -- Matt
ijuma
Indeed. But realistically speaking, we are talking only about the
integration of the Google summer of code project (highlight implicit
applications). The reason why this is not in 2.9 is mostly because we
are not sure we can have it fast enough (it requires full type
checking.. can we do that fast enough for each keystroke?).
To summarize, you suggest that we wait and merge the two branches
before a release? Or that the current state is not good enough for a
release?
iulian dragos
Agreed. We should have a more general mechanism for such things.
>
> Eugene.
>>
>> -- Matt
iulian dragos
>> Indeed. But realistically speaking, we are talking only about the
>> integration of the Google summer of code project (highlight implicit
>> applications). The reason why this is not in 2.9 is mostly because we
>> are not sure we can have it fast enough (it requires full type
>> checking.. can we do that fast enough for each keystroke?).
>
> I think these are very valid concerns. They should apply to both branches
> though, right? Maybe it should be disabled by default in 2.8.1 too?
In a sense, yes, if we had a 2.8.1 version which was based strictly on
wip_experiment. However, the backport branch is an effort to backport
important fixes from wip_experiment, including the compiler part.
However, it does not contain all the changes, , and I don't think it
has the same stability characteristics, so disabling this won't make
it as stable as 2.9 anyway. I think we should be very clear: backport
is a 'best effort' for 2.8.1, based solely on David's efforts.
>>
>> To summarize, you suggest that we wait and merge the two branches
>> before a release? Or that the current state is not good enough for a
>> release?
>
> I haven't used any of the two branches for long enough so I am probably not
> the best person to give advice on this. From discussions on the mailing
> list, it seemed like there was a much stricter approach on what would go in
> the 2.9.0 branch versus what would go in the 2.8.1 branch. I don't know if
> this has had a real effect on reliability and/or stability, but if it did,
> then I would make that very clear in the message.
I will draft a better explanation of the two branches. As I mentioned
before, some of the fixes in the compiler are not in backport,
therefore the feature matrix is only half of the story. I'll see to
clarify the other half.
> For example, in the
> Features page, this is explained in the text, but not in the table. If
> someone was just skimming the table, they would not know.
> With that out of the way, I'm very happy to see progress being made on the
> Eclipse side of things. IDEA is pretty good these days and with SBT 0.9 on
> the way, it seems like the tooling situation for Scala is improving very
> quickly. :)
Cool!
David Bernard
-- Matt
David Bernard
Eugene.
>
> -- Matt
Mirko Stocker
> > Mark occurrences runs as an Eclipse job, i.e. asynchronously.
> > For other actions that provide highlighting upon a type-check finish I
> > think the presentation compiler should provide a callback interface.
>
> Agreed. We should have a more general mechanism for such things.
By the way, there's an experimental feature in wip_exp_backport that marks
unused imports, I guess this could also benefit from such a callback (I'm not
sure how it's implemented at the moment). Also, I could use something like
that for my "eliminating pattern matches" quickfixes / refactorings.
--
Mirko Stocker | m...@misto.ch
Work: http://ifs.hsr.ch | http://infoq.com
Personal: http://misto.ch | http://twitter.com/m_st
Mirko Stocker
> wip_exp_backport include a list of listener where some tools can register
> to rbe called (and run) before or after reconcialiation.
Oh, that just answered my question, thanks :-)
David Bernard
Indeed. But realistically speaking, we are talking only about the
integration of the Google summer of code project (highlight implicit
applications). The reason why this is not in 2.9 is mostly because we
are not sure we can have it fast enough (it requires full type
checking.. can we do that fast enough for each keystroke?).I think these are very valid concerns. They should apply to both branches though, right? Maybe it should be disabled by default in 2.8.1 too?
David Bernard
On Saturday 26 March 2011 09:47:33 iulian dragos wrote:By the way, there's an experimental feature in wip_exp_backport that marks
> > Mark occurrences runs as an Eclipse job, i.e. asynchronously.
> > For other actions that provide highlighting upon a type-check finish I
> > think the presentation compiler should provide a callback interface.
>
> Agreed. We should have a more general mechanism for such things.
unused imports, I guess this could also benefit from such a callback (I'm not
sure how it's implemented at the moment). Also, I could use something like
that for my "eliminating pattern matches" quickfixes / refactorings.
Mirko Stocker
> I tried, but I didn't register "unused import" in this mecanism.
> Because unused import is usefull as marker on all the files of the project
> not only the currently editing.
> The current integration of "unsused import" is "crappy", because it use
> info from presentation compiler but it runs during "build" phase (after
> regular compiler).
> I hope to improve the situation when more time (it's not blocker and
> already useable).
Maybe we need something like Codan [1] for Scala :-) Maybe I should try to
build something like this? Not for our next round of releases, but for a
future version.
Cheers,
Mirko
[1] http://wiki.eclipse.org/CDT/designs/StaticAnalysis
David Bernard
On Fri, Mar 25, 2011 at 8:52 PM, ijuma <ism...@juma.me.uk> wrote:In a sense, yes, if we had a 2.8.1 version which was based strictly on
>> Indeed. But realistically speaking, we are talking only about the
>> integration of the Google summer of code project (highlight implicit
>> applications). The reason why this is not in 2.9 is mostly because we
>> are not sure we can have it fast enough (it requires full type
>> checking.. can we do that fast enough for each keystroke?).
>
> I think these are very valid concerns. They should apply to both branches
> though, right? Maybe it should be disabled by default in 2.8.1 too?
wip_experiment. However, the backport branch is an effort to backport
important fixes from wip_experiment, including the compiler part.
However, it does not contain all the changes, , and I don't think it
has the same stability characteristics, so disabling this won't make
it as stable as 2.9 anyway. I think we should be very clear: backport
is a 'best effort' for 2.8.1, based solely on David's efforts.
David Bernard
David Bernard
David Bernard
Martin Gamwell Dawids
On Mar 25, 4:24 pm, Ruediger Keller <ruediger.kel...@rk42.de> wrote:
> Hello,
>
> I'm following this discussion somewhat and just wanted to add some
> thoughts of mine.
have read everything in this thread.
However, I would just like to point the attention to the OSGi
versioning semantics which are described in a number of places, e.g.
in the book "OSGi and Equinox" by Jeff McAffer et al. On page 155,
section 9.4.1 "Version and Version Ranges" it reads:
> Version numbers in OSGi are made up of four parts:
> major.minor.service.qualifier:
>
> * Major -- Differences in the major part indicate significant
> differences such that backward compatibility is not guaranteed.
> * Minor -- Changes in the minor part indicate that the newer version
> of the entity is backward compatible with the older version, but it
> includes additional functionality and/or API.
> * Service -- The service part indicates the presence of bug fixes and
> minor implementation (i.e., hidden) changes over previous versions.
> * Qualifier -- The qualifier is not interpreted by the system. Qualifiers are
> compared using standard string comparison.
>
> Following these numbering semantics is important. As parts of the
> system come to depend on one another, they need to know about
> changes in the compatibility contract as well as updating their requirements.
I believe this should be taken into consideration when choosing a
version numbering scheme. E.g. new functionality that is backwards
compatible should be reflected by an incremented minor number (and not
only an incremented service number.)
The OSGi Core specification (r4.core.pdf) also describes versioning
schemes in sections:
* 3.6.2 Version Matching
* 6.1.28 Describing class Version
* 6.1.28.5 Describing compareTo of class Version
(which implements Comparable)
/Martin
iulian dragos
Cheers/davidB
David Bernard
ijuma
I think it's a good approach, but I would simplify it a bit, following git-flow more closely.I think we should have only two branches: 'solid' and 'develop', and many other development branches for each feature.