Community
Participate
Working Groups
I would like to propose that we update the Mylyn Reviews versions to 2.0.0. The latest changes to the model are causing breakage for most clients (even though packages are exported as x-internal) and we are planning to make other substantial changes such as bug 381265.
+1. There will likely be other changes coming as well as we integrate some of the functionalities of R4E into the Mylyn reviews codebase (e.g. workspace integration, inline comments, common navigator improvements etc.) /Sebas
+1. We're likely to see more significant model changes as well as changes to the way models are updated. (Though as much as possible we'll try to make these changes non-breaking, it's likely there will be some.) The new capabilities might justify a major version update as well. Would we be shooting for Kepler for the actual release?
(In reply to comment #2) > Would we be shooting for Kepler for the actual release? We haven't finalized the plans. Some time around EclipseCon or Kepler seem most likely.
(In reply to comment #3) > (In reply to comment #2) > > Would we be shooting for Kepler for the actual release? > > We haven't finalized the plans. Some time around EclipseCon or Kepler seem most > likely. FWIW, we'll probably be mid-course on some of the major changes we've been contemplating w/ R4E team when EclipseCon roles around. It would be really ideal to see them in for Kepler but we'd have a lot of changes pushing up into right before the RCs. We might need to contemplate a branch at that point and focus on nailing down the (pseudo) APIs so that we don't have to go though another version bump after.
We're going to have to search for a good gap on reviews right now to do this. Currently we have four in queue.
(In reply to comment #4) > We might need to contemplate a branch at that point and focus on > nailing down the (pseudo) APIs so that we don't have to go though another > version bump after. We should do this sooner rather than later to not catch integrators by surprise. It would be good if you could push a review for this change. The current plan is to release 3.9/2.0 with Kepler so we still have time to iterate over the API.
(In reply to comment #6) > (In reply to comment #4) > We should do this sooner rather than later to not catch integrators by surprise. > It would be good if you could push a review for this change. Agreed. I'll slide it in after https://git.eclipse.org/r/#/c/10247/ but before whatever comes of https://git.eclipse.org/r/#/c/11012/. There are just too many other manifest changes that I think putting it in before the current batch would make for a lot of uneccesary merging. > The current plan is to release 3.9/2.0 with Kepler so we still have time to > iterate over the API. Great.
https://git.eclipse.org/r/#/c/11135/ Steffen, I've bumped all of the stuff in tbr as well -- wasn't totally comfortable w/ that, but I think you've mentioned that builds that span version numbers don't work well, and indeed I couldn't get it to work w/o that.
From Miles: > 1. Why do we have something in versions namespace here? The bundles have dependencies on tasks and were moved to the reviews repository due to that reason. We didn't bother to update the namespace at the sime. > 2. There don't seem to be any features, so this isn't actually being provided anywhere??? Does it need to be in build at all? Should it perhaps be in a branch somewhere? (IIRC the tasks.mapper stuff has caused some headaches w/ downstream builds before.) I don't know what you mean by headaches. AFAIK, the bundles build fine so there is no reason to remove them right now. > 3. Finally, does anyone have an issue w/ us bumping the version on these to 2.0.0 or absent that have another idea? Please leave TBR at the current version unless Kilian wants them to be updated. Tycho can handle repositories with different bundle versions without any problem. You just have to set versions in pom to match manifests.
(In reply to comment #9) > I don't know what you mean by headaches. AFAIK, the bundles build fine so there > is no reason to remove them right now. o.e.m.versions.tasks.mapper.tests was breaking on http://ci.mylyn.org and it isn't building locally for me either. it's not biggie since we're not using those builds anymore anyway. (In any case it looks like that server is down.) > Please leave TBR at the current version unless Kilian wants them to be updated. > Tycho can handle repositories with different bundle versions without any > problem. You just have to set versions in pom to match manifests. Okay, I must have misinterpreted something you said a while ago re: that. Will do.
Merged.. https://git.eclipse.org/r/#/c/11135/ https://git.eclipse.org/r/#/c/11136/
Miles, please make sure bugs are always assigned to the person who completed the majority of the work when resolving them.
Oversight. While on the subject, is it generally ok to self-assign a task? I thought it was ok whenever we started work on something, but I sort of remember there being an issue w/ this at some point.
(In reply to comment #13) > Oversight. While on the subject, is it generally ok to self-assign a task? I > thought it was ok whenever we started work on something, but I sort of remember > there being an issue w/ this at some point. Yes, committers should assign tasks to themselves (or the respective contributor) and to the milestone when working on a task or committing to completing it for a release. Tasks that should show on the generated project plan should be marked with the "plan" keyword.
