Release 1.3.0 #816
Comments
|
+1 |
|
Good to see that we have consensus - as for the process, is it necessary to create an RC1 tag first? As far as I can tell the release process is as follows:
Are those steps correct? |
|
Hi all,can you please wait until tomorrow. I wanted to test the issue with the empty configuration.On the first sight it only worked for Configurations but not for the FactoryConfiguration. I wanted to verify this.Regards,Mark Hoffmann M.A. Dipl.-Betriebswirt (FH) CEO/CTO Phone: +49 3641 384 910 0 Mobile: +49 175 701 2201 E-Mail: ***@***.*** Web: www.datainmotion.de Data In Motion Consulting GmbH Kahlaische Strasse 4 07745 Jena Germany Geschäftsführer/CEO Mark Hoffmann Jürgen Albert Jena HRB 513025 Steuernummer 162/107/05779 USt-Id DE310002614
-------- Ursprüngliche Nachricht --------Von: Tim Ward ***@***.***> Datum: 29.02.24 16:43 (GMT+01:00) An: osgi/osgi-test ***@***.***> Cc: Mark Hoffmann ***@***.***>, Mention ***@***.***> Betreff: Re: [osgi/osgi-test] Release 1.3.0 (Issue #816)
Good to see that we have consensus - as for the process, is it necessary to create an RC1 tag first?
As far as I can tell the release process is as follows:
Create two commits locally on main, the first changing the revision to a release version, the second to the next development version.
Push the two commits together to main (to avoid a build of the release without a tag)
Use the GitHub release tooling to tag the commit with the release version
After the release has been built upload any artifacts to the GitHub release.
Are those steps correct?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
See https://github.com/osgi/osgi-test/wiki/Release-Process where the process is documented. |
@maho7791 if you do find a problem please include a test case, as the current unit tests pass. I am starting to use this function and have not yet seen any problems. |
|
👍 Just wanted to add a big thank you to all those who have been working hard on osgi-test. Current circumstances do not permit my involvement to the level I have been involved in the past, and besides I'm not that familiar with the OSGi Configuration Manager (which is where it seems most of the activity is happening) so I'm happy to leave this to more experienced heads anyway. 😄 But just based on the amount of activity, it does seem like a new release would be timely. Congratulations team, keep up the good work! |
They look broadly correct to me, though I've never been intimately involved in a release. @bjhargrave linked to the detailed steps above, but I just wanted to highlight one step that is often overlooked in our enthusiasm to get things out - updating the release notes: https://github.com/osgi/osgi-test/wiki/Release-Notes-1.3.0 It's important so that you can all brag about all your hard work. 😉 |
|
I've created the RC1 tag and updated the release notes. Hopefully all will be well and we can release at some point next week. |
|
Attempting to test with the osgi/osgi build has flagged a longstanding issue - our dependency tree is somewhat mismatched. Our base level of JUnit Jupiter is 5.6 (i.e. very old) but our base level of assertj is 3.24 (i.e. very new). The assertj code optionally requires JUnit Jupiter at 5.10. As we don't directly use the assertj JUnit API the uses constraint isn't triggered and you can therefore deploy a set of bundles which do this: I have tried rolling back to assertj 3.19 (the newest version that supports JUnit 5.6), but that causes test failures when running with the latest assertj. I think we will need to establish something in the middle, perhaps a mutual dependency on JUnit 5.8? Does that seem like an acceptable compromise? If not then we can leave things as they are, but warn people to use a new enough JUnit Jupiter to satisfy assertj. |
|
This is why smoke testing with the osgi/osgi build is useful :-) |
|
1.3.0.RC2 is now tagged. Please let me know of any more issues that we find. UPDATE the RC2 build works in the osgi/osgi build |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There have been numerous fixes and enhancements since the release of 1.2.1, and the list of outstanding issues has been almost totally completed.
I propose that it's time to release 1.3.0 - what do you all think?
@stbischof @maho7791 @juergen-albert @bjhargrave @rotty3000 @kriegfrj
The text was updated successfully, but these errors were encountered: