eclipse-aspectj / aspectj

Other
303 stars 86 forks source link

Release 1.9.8 #121

Closed kriegaex closed 2 years ago

kriegaex commented 2 years ago

This PR has evolved into a release PR, because in the same branch I just added the commits which led to release 1.9.8. After merging this, we will have a 1.9.9-SNAPSHOT development version.

Besides, I am not sure you tagged my previous releases. @aclement, maybe you want to add and push the tags which are not in the upstream repo yet:

$ git tag --list 'V1_9_[678]*' --format "%(objectname) %(refname:short)"

3d7bc042885bb01697fbd5004fe36cf6c274cfea V1_9_6
a22efad2542a2252c8803d0083b80855826b97a7 V1_9_7
08c6b70963e778bf2d12f063b833a2f544b9d37c V1_9_7_M2
9721f936bd8c7b8e95c100d7b2d0261950f8a80c V1_9_7_M3
c8da9556e21be5b919c3f74d868202d7e564e17c V1_9_8
4b2be42d2e9d1c979803f6e2d9a0a1673bc285d6 V1_9_8_M1
7eeb27c73003bff73ccf4829310097a540926f98 V1_9_8_RC1
5d4f2c2a6b5df574360e5c5fac6ce6a5cbea833f V1_9_8_RC2
d2588d086ff61d65cd90a376732ae1b9b4d646dd V1_9_8_RC3

$ git tag --list 'V1_9_[678]*' | xargs -n 1 git log --oneline -1

3d7bc0428 (tag: V1_9_6) AspectJ 1.9.6 final bits
a22efad25 (tag: V1_9_7) 1.9.7 release
08c6b7096 (tag: V1_9_7_M2) Set version to 1.9.7.M2
9721f936b (tag: V1_9_7_M3) Set version to 1.9.7.M3
c8da9556e (tag: V1_9_8) Set version to 1.9.8
4b2be42d2 (tag: V1_9_8_M1) Set version to 1.9.8.M1
7eeb27c73 (tag: V1_9_8_RC1) Release version to 1.9.8.RC1
5d4f2c2a6 (tag: V1_9_8_RC2) Set version to 1.9.8.RC2
d2588d086 (tag: V1_9_8_RC3) Set version to 1.9.8.RC3

Old subject and PR description:

IDE.md points to AJDT Eclipse update sites

Because the Jenkins builds for Eclipse now exist and deploy to the correct update sites, we no longer need the AspectJ.dev ones.

kriegaex commented 2 years ago

@aclement, you forgot the tags. Assuming that this repository is your origin, it should be something like this (only the missing ones, I filtered out the existing ones already):

git tag V1_9_7_M2 08c6b70963e778bf2d12f063b833a2f544b9d37c
git tag V1_9_7_M3 9721f936bd8c7b8e95c100d7b2d0261950f8a80c
git tag V1_9_8_M1 4b2be42d2e9d1c979803f6e2d9a0a1673bc285d6
git tag V1_9_8_RC1 7eeb27c73003bff73ccf4829310097a540926f98
git tag V1_9_8_RC2 5d4f2c2a6b5df574360e5c5fac6ce6a5cbea833f
git tag V1_9_8_RC3 d2588d086ff61d65cd90a376732ae1b9b4d646dd
git tag V1_9_8 c8da9556e21be5b919c3f74d868202d7e564e17c

git push origin V1_9_7_M2
git push origin V1_9_7_M3
git push origin V1_9_8_M1
git push origin V1_9_8_RC1
git push origin V1_9_8_RC2
git push origin V1_9_8_RC3
git push origin V1_9_8
aclement commented 2 years ago

no, I didn't forget any tags, I just didn't have time.

aclement commented 2 years ago

tags are done. or should I say tag, the only tag I hadn't gotten locally was 1.9.8 so they just needed pushing.

kriegaex commented 2 years ago

Thank you so much. Wow, you even created a GitHub release for 1.9.8. Nice. 🙂

Like I said before, my script would have worked independently of whether you had the tags locally or not. The commit IDs would have been the same, because like I also said before on Slack, I had rebased the PR correctly in order not to overwrite the 1.9.8 tag. So everything would have been identical anyway. The only reason I can think of for you having some of my tags for milestones and release candidates is that you pulled them from my fork when building locally.