| Hi Zoltan,
see my comments below.
Hi,
in general, these changes sound great to me; however, I have a few comments.
1) I second moving everything. It makes much more sense long-term.
Fine. 2) I would be careful about renaming repositories; it could cause strange surprises, e.g. the GEF repository at github ( https://github.com/eclipse/gef) was forked 34 times, and starred 13 times. Simply renaming is entirely ok, but then moving another repository to have the same name can be a source of confusion…
Up to now the repositories are only mirrored, so I suppose they will have to replaced anyway. I don’t know how that could be done in a way that forks can be preserved (or if its possible at all). I will try to find that out and add respective comments to https://bugs.eclipse.org/bugs/show_bug.cgi?id=495455.
3) I have no problems with another major release; especially that I had played a bit with Zest, and will have a few recommendations to update it (but will most likely require API changes).
My impression is the same. The major will already be needed to drop Java-7 support, but it will also give us the flexibility to further clean up the API.
4) What is not clear to me in this proposal whether release update site urls would be changing. I have no problem with changing CI update site urls, but release urls should remain stable (or at least, redirect to the new ones, e.g. with a composite repository), as they can be referred to in existing installations as well.
Yes, I am thinking of actually changing the update sites for the GEF 3.x components as follows:
-Draw2d 3.x / GEF (MVC) 3.x, Zest 1.x Releases:
Draw2d 3.x / GEF (MVC) 3.x, Zest 1.x Milestones:
-Draw2d 3.x / GEF (MVC) 3.x, Zest 1.x Integration:
If we could keep the old urls in place through symlinks for now (I have played a bit with using symbolic links yesterday and have contacted the webmaster for help), this is something I would like to adjust already today, so we would already have them in place for Neon (which would allow us to start using the original urls for the Oxygen train). It would also allow mirrors to properly sync during the quiet week. We could then think of further options (leave the symlinks, replace them with new content, aggregate them in a composite repo) after the Neon release.
Best regards,
Zoltán
-- Zoltán Ujhelyi
Regards, Alexander
Eclipse Technologies Expert IncQueryLabs Ltd. On 06 Jun 2016, at 10:34, Fabian Steeg <steeg@xxxxxxxxxx> wrote:
Hi,
sounds great, +1 on all those points.
And btw, yay for moving to Java 8 after Neon :-) [1]
Cheers,
Fabian
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=495456
On 04.06.2016 09:58, Alexander Nyßen wrote:
Hi team,
while we have already agreed on migrating our code base from
git.eclipse.org <http://git.eclipse.org> to GitHub (replacing the up to
now mirrored repositories there), we had not clarified all the details.
I want to initiate the migration soon after the Neon release
(unfortunately there was no time to do so earlier) and had some thoughts
about it in the mean time:
1) We had discussed earlier whether to migrate only the GEF4 code base,
but having considered this in detail in the last weeks, I would propose
to migrate both Git repositories (GEF 3.x and GEF4). First, because this
is the intended policy of the Eclipse foundation to have all
repositories in a single place, so we would need an exception otherwise.
Second, because, as GEF 3.x is in pure maintenance mode now, hosting its
code base at GitHub would give adopters an easier chance to maintain a
fork, if needed.
2) As GEF4 supersedes GEF 3.x, I would like to take the migration as an
opportunity to ‚flip the switch‘ during the Oxygen train. That is, I
would like to use 'eclipse/gef‘ accordingly as the name of GitHub ‚GEF4'
repository, and introduce 'eclipse/gef3' as name for the repository that
contains the old GEF 3.x code base.
3) Further, I would propose to plan another major release (5.0.0) for
Oxygen, and there adopt the ‚GEF4' code base to the original project
namespace, migrating all ‚GEF4' bundles and features from the
org.eclipse.gef4.* namespace to the original org.eclipse.gef.* namespace
(and adopting their versions to 5.0.0 instead of 2.0.0). This could be
done without colliding with the GEF 3.x bundles and features (so we
would not have to rename these).
4) Last, I would propose to adopt our Hudson build jobs and update site
urls, as well as artifacts names to use gef3 for the old code base, and
gef for the new one.
What do you think? Comments welcome!
Regards,
Alexander
--
Dr. Alexander Nyßen
Dipl.-Inform.
Principal Engineer
Telefon: +49 (0) 231 / 98 60-202
Telefax: +49 (0) 231 / 98 60-211
Mobil: +49 (0) 151 / 17396743
http://www.itemis.de
alexander.nyssen@xxxxxxxxx <mailto:alexander.nyssen@xxxxxxxxx>
itemis AG
Am Brambusch 15-24
44536 Lünen
Rechtlicher Hinweis:
Amtsgericht Dortmund, HRB 20621
Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus,
Jennifer Fiorentino
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gef-dev
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gef-dev
_______________________________________________ gef-dev mailing list gef-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/gef-dev
-- Dr. Alexander Nyßen Dipl.-Inform. Principal Engineer Telefon: +49 (0) 231 / 98 60-202 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743 http://www.itemis.de alexander.nyssen@xxxxxxxxx itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
|
