Closed laeubi closed 2 years ago
Created a release https://projects.eclipse.org/projects/science.chemclipse/releases/0.8.0-2020-06 and IP-Log review https://dev.eclipse.org/ipzilla/show_bug.cgi?id=21745
Christoph,
have you requested to "create a new release" via the committer tools section? https://projects.eclipse.org/projects/science.chemclipse
Please note: ChemClipse depends on Eclipse SWTChart. So, SWTChart needs to released too.
Best, Philip
Am 01.03.20 um 12:13 schrieb Christoph Läubrich:
Created a release https://projects.eclipse.org/projects/science.chemclipse/releases/0.8.0-2020-06 and IP-Log review https://dev.eclipse.org/ipzilla/show_bug.cgi?id=21745
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/eclipse/chemclipse/issues/268?email_source=notifications&email_token=AAFHUT3CTIIGLVP7Q5IOGG3RFI7OBA5CNFSM4K7D4DTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENM4CRA#issuecomment-593084740, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFHUTZCZKO7EZT5KFVOJQLRFI7OBANCNFSM4K7D4DTA.
--
OpenChrom - the open source alternative for chromatography / mass spectrometry
Dr. Philip Wenig » Founder » philip.wenig@openchrom.net » http://www.openchrom.net
have you requested to "create a new release" via the committer tools section?
Yes see links above.
SWTChart needs to released too
As Linux-Tools also depends on SWT-Chart I think there is a strong reason to start the release process ASAP for SWT-Chart, I hoped that https://github.com/eclipse/swtchart/issues/111 is for tracking this. If not it would be good if you @eselmeister as a committer of the swtchart project could trigger this right now, I think @akurtakov would also appreciate it.
SWT-Chart was changed to the official release now and Release-review is in progress, but it has been proven that we better release a 0.8.0 first, then upgrade to latest eclipse+java11 in 0.9.0 because otherwhise its hard to integrate with the current eclipse tech-stack.
Before we proceed with ChemClipse 0.9.0 and Eclipse + Java 13, let me first finish to remove the JavaFX code. https://github.com/eclipse/chemclipse/issues/281
I'll give a feedback as soon as this has been resolved.
Am 13.03.20 um 06:21 schrieb Christoph Läubrich:
SWT-Chart was changed to the official release now and Release-review is in progress, but it has been proven that we better release a 0.8.0 first, then upgrade to latest eclipse+java11 in 0.9.0 because otherwhise its hard to integrate with the current eclipse tech-stack.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eclipse/chemclipse/issues/268#issuecomment-598554943, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFHUTZ5YODYV6ZRIC3MLLDRHG7GXANCNFSM4K7D4DTA.
--
OpenChrom - the open source alternative for chromatography / mass spectrometry
Dr. Philip Wenig » Founder » philip.wenig@openchrom.net » http://www.openchrom.net
That sounds reasonable.
The release was approved now, I would suggest the following if you are fine with that:
@eselmeister WDYT?
Removing the JavaFX is a challenge. I'm making good progress in removing it from the PCA tools. The 3D plot needs to be replaced by a native widget, but I didn't find a good solution yet. Additionally, all of our company related JavaFX parts needs to be refactored too. in summary, it will take a while.
In the 0.9.x version, I would also recommend to switch to "org.eclipse.e4.legacy.ide.application" instead of the ChemClipse Application.e4xmi model. I already have experience how to modify the existing fragment.e4xmi files.
@laeubi Let's keep our plans in synch and inform each other via email, mailing list or tickets in time. As you know, I have a heavy workload at the moment. I don't want to run into extra troubles, which could have been avoided.
I would suggest then the following:
That way from your point of view (and for example openchrom) chemclipse will stay stable.
About the applicationmodel we should check if we can even migrate to the generic xpath based binding available in newer eclipse versions as this would allow to install chemclipse into any E4 application, from my point of view this is something for the 0.9.x release
+1 for doing a 0.8.0 release as soon as it gets approved by the Eclipse Foundation.
I'm worried about keeping the branch "develop" for the 0.8.x line as we are integrating a lot of new code and improvements into develop. When using a master branch for the 0.9.x development, it could diverge over the time too much from the develop branch, which makes it the harder to merge.
I would recommend to keep the branch "develop" as the main branch for developments. It is also set as a default at the ChemClipse GitHub page. We should try to improve develop as best as possible, so that we get rid of all issues that hinder us from migrating to Java 13/14 and the latest Eclipse version. Branches could be opened for short periods for improving works. E.g., refactoring the JavaFX / PCA stuff is quite hard. The branch is open for ~1 week now. That's quite too long, but I'm quite confident that I'm able to finish the refactoring by the beginning of next week. It will be merged into develop.
Regarding the application model XPath stuff. I'm also not a friend of trying to use too much helper tools to get things done. The easier, the better. Effectively, to use the legacymodel, the master ids need to be adjusted only. I did this for a customer project already. Let's chat. I have another meeting now.
Am 19.03.20 um 11:31 schrieb Christoph Läubrich:
I would suggest then the following:
- we do the release for 0.8.0 as soon as approved by Eclipse but keep the develop as the branch for the 0.8.x line
- when the release is done we update the master branch with develop and use that for the 0.9.x line development
- bugfixed could be backported then either from 0.9.x -> 0.8.x or vice versa via pull-requests.
- new features are only ported from 0.8.x -> 0.9.x if desirable (I can take care of this) also via pull-requests
- once you are ready to port to 0.9x. line we can release a 0.8.1 version to account for changes between now and then, and then make the master the new develop
- for 0.10.x (or probably even a 1.0.x) we can do the same, so there is always support for the last two major versions to allow adoption of downstream projects.
That way from your point of view (and for example openchrom) chemclipse will stay stable.
About the applicationmodel we should check if we can even migrate to the generic xpath based binding available in newer eclipse versions as this would allow to install chemclipse into any E4 application, from my point of view this is something for the 0.9.x release
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eclipse/chemclipse/issues/268#issuecomment-601105097, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFHUT4YJPLCKKUA3XF2WXDRIHX7JANCNFSM4K7D4DTA.
--
OpenChrom - the open source alternative for chromatography / mass spectrometry
Dr. Philip Wenig » Founder » philip.wenig@openchrom.net » http://www.openchrom.net
That different release diverge is something we can't really avoid, this was just an idea to keep your changes low when switching over from 0.8.x to 0.9.x, as existing builds don't need to be adjusted.
If you are fine to integrate all possible breaking changes that would occur with the 0.9.x line I'm fine with that I just wanted to offer an alternative to immediate migration of dependent non open sourced projects.
Thanks for taking care of it. I'd also like to move forward to the latest Java and Eclipse version. Let me think about this and its implications a few days.
Am 19.03.20 um 19:22 schrieb Christoph Läubrich:
That different release diverge is something we can't really avoid, this was just an idea to keep your changes low when switching over from 0.8.x to 0.9.x, as existing builds don't need to be adjusted.
If you are fine to integrate all possible breaking changes that would occur with the 0.9.x line I'm fine with that I just wanted to offer an alternative to immediate migration of dependent non open sourced projects.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eclipse/chemclipse/issues/268#issuecomment-601340069, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFHUTYXKRONZJ76SSANHZLRIJPF5ANCNFSM4K7D4DTA.
--
OpenChrom - the open source alternative for chromatography / mass spectrometry
Dr. Philip Wenig » Founder » philip.wenig@openchrom.net » http://www.openchrom.net
As SWT-Chart is preparing for joining the Eclipse SimRel ( see https://github.com/eclipse/swtchart/issues/111 and https://github.com/eclipse/swtchart/pull/110 ) I think it would make sense to also join the release train with ChemClipse to make ChemClipse more stable and visible.
There are also some outstanding issues that are better solved in a new release so dependent projects (like OpenChrom) can decide weather they like to catch-up immediately or stay at a stable branch for a while.
The major steps for this would be: