After some further discussion and some new insights some of us think the choice for a v1.0 is not the right thing at the moment. We think that we need one further release v0.12.0 before a v1.0.0 release by the end of the first quarter next year. The content and planning of the current release has not changed. Just the version number we link to this release will change.
We have added a couple of large changes like K8s v1.20 dependency support in [1]. Message changes between the shim and core in [2]. Node sorting changes in [3]. K8s has already released two later versions from which K8s v1.22 has some API changes that affect us. It also moves to a later version of protobuf and gRPC. These two changes have a significant impact on the code and build process. We need to make those changes as part of a v1.0 release and not as part of a minor release after v1.0. The predicate implementation using the scheduling framework was required for K8s v1.20. It has opened up the possibility to move YuniKorn in the direction of the framework for a more seamless integration into K8s. A POC is currently on its way and the hope is to have that as part of v1.0. I will start updating jira project and move the jiras to the new release from today. This does not have an impact on any of the work that is ongoing. Wilfred [1] https://issues.apache.org/jira/browse/YUNIKORN-872 [2] https://issues.apache.org/jira/browse/YUNIKORN-337 [3] https://issues.apache.org/jira/browse/YUNIKORN-780 On Tue, 26 Oct 2021 at 18:04, Wilfred Spiegelenburg <[email protected]> wrote: > I saw that we already have a JIRA filter for 1.0 >> <https://issues.apache.org/jira/projects/YUNIKORN/versions/12350288>. >> > > The release and version information is only available if and when you are > authenticated to jira. That excludes people. > For unauthenticated access it is better to use searches like the ones > already available: > Current release target: > https://issues.apache.org/jira/issues/?filter=12348416 > Fixed in 1.0.0: https://issues.apache.org/jira/issues/?filter=12350818 > These links we can also include in a release preparation page on the > website. > > It does come back to properly using the "target version" and "fixed in > version" fields. > Using the fixed in version field for release planning causes issues as it > requires bulk updates for issues that miss a release. > If the issue slips the release it has to be updated otherwise the release > note shows issues as included while they are still open. > Using two fields allows us to target a fix for an issue in a release > without impacting the release notes. > It will become more important when we start creating maintenance releases > on top of older releases with backports. > > Wilfred > >
