Hi Wilfred Thank you for the updates! On Sun, Nov 7, 2021 at 9:57 PM Wilfred Spiegelenburg <[email protected]> wrote:
> 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 > > > > >
