Hi Chris

Agree that this is indeed a non-technical issue. We need to be more cautious 
about our dependencies on snapshot versions when releasing. We will pay 
attention to this in future releases.

In my opinion, the slow release pace of Ratis is also a non-technical issue, as 
reaching a consensus within the entire community takes time. For example, we 
may only want to introduce a few patches we've fixed in the new version, but 
the Ozone community may want to introduce a few other patches. If there are 
problems with some of these patches that need further improvement, it could 
lead to release delays. After all, the Ratis community releases official 
versions not only for the Ozone community or IoTDB community.

In the future, when IoTDB is releasing new versions, we will try to reach out 
to the Ratis community in advance to achieve our goals.

Xinyu Tan

On 2023/09/14 05:46:07 Christofer Dutz wrote:
> Hi Xinyu,
> 
> I totally understand the reasoning behind it. There however is a 
> non-technical issue that I see for which we should not release SW that relies 
> on SNAPSHOTS.
> 
> If we do this, we are practically embedding software in our software, which 
> has not formally been approved by a PMC. This is more a legal topic.
> 
> Are the Ratis folks having technical issues with releasing? I know many 
> projects at Apache write awesome software, but have problems maintaiing their 
> build infrastructure. Perhaps that’s something I could help them with?
> 
> And I guess we don’t need a new Ratis release for ever IoTDB release, right?
> 
> Chris
> 
> Von: Xinyu Tan <[email protected]>
> Datum: Donnerstag, 14. September 2023 um 07:02
> An: [email protected] <[email protected]>
> Betreff: Re: AW: Ratis SNAPSHOT versions in our latest release ...
> Hi, Chris
> 
> As mentioned by William, initially, we relied solely on the snapshot version 
> of Ratis in the master branch to quickly validate many new bug fixes and 
> features (just counted, we've added around 60 patches to the Ratis community 
> in the past year). In fact, when we released a new version of IoTDB earlier 
> this year, we attempted to encourage the Ratis community to release a new 
> version as well. However, due to issues with some other patches in the 
> community, the release went through multiple release candidates (rc), 
> ultimately lasting close to one month, which affected IoTDB's release 
> schedule.
> 
> Looking back, in 2023, IoTDB released nearly 7 versions, while the Ratis 
> community released only 2 versions. This has led us to the need to find a 
> solution to balance the issues arising from different release speeds. 
> Depending on a long-standing snapshot version is a last resort for us.
> 
> Fortunately, with further collaboration between IoTDB and Ratis, Ratis in the 
> context of IoTDB has recently become relatively stable. Therefore, we 
> anticipate that in future releases, we will make an effort to ensure that 
> IoTDB's release version also includes an official version of Ratis to avoid 
> potential risks.
> 
> Thanks for Chris's reminder!
> 
> Xinyu Tan
> 
> On 2023/09/13 14:31:13 Christofer Dutz wrote:
> > Hi all,
> >
> > after some discussions with colleagues it turns out that it’s not quite as 
> > dramatic as I first throuhgt. So first I thought the commit hash was some 
> > way to address one fixed SNAPSHOT version via some mechanism I just didn’t 
> > know yet, but it turns out to be a lot simpler …. It produces a SNAPSHOT 
> > for version “2.5.2-a4398bf“ … so it’s an artificial version for which then 
> > again 3-5 SNAPSHOTS will be keept.
> >
> > Seems it’s some shorthand version of inofficially releasing things without 
> > actually releasing them.
> >
> > So it’s still not ideal, as the referenced artifacts will never go to Maven 
> > Central and could cause problems with the one or the other user, I don’t 
> > see it as an immediate threat.
> >
> > Chris
> >
> > Von: Christofer Dutz <[email protected]>
> > Datum: Mittwoch, 13. September 2023 um 11:01
> > An: [email protected] <[email protected]>
> > Betreff: Ratis SNAPSHOT versions in our latest release ...
> > Hi,
> >
> > I’m currently working on resolving some of the dependency version issues we 
> > are having.
> > Mostly people will not have noticed, but currently we’re pulling in up to 4 
> > different versions of a jar in our build. This can cause many extremely 
> > hard to spot problems.
> >
> > While trying to fix a problem with metrics-core in version 4.2.7 but 
> > pulling in on older version in Ratis I noticed us using:
> >
> > <ratis.version>2.5.2-a4398bf-SNAPSHOT</ratis.version>
> >
> > This is extremely problematic. Currently the Apache Nexus server only keeps 
> > 5 SNAPSHOT versions and then deletes old ones. This means that we regularly 
> > have to bump the SNAPSHOT version of Ratis.
> >
> > This got me thinking and I checked the release branch for the 1.2.x branch. 
> > Here we’re using the same.
> >
> > The problem with using SNAPSHOTS on master is not that severe, but using 
> > them in releases it very problematic. I guess we’ll only be able to build 
> > our last release for a few more days/weeks and then it will no longer be 
> > buildable.
> >
> > Are we relying on things in Ratis, that are not yet released?
> >
> > We should probably encourage the Ratis folks to head for a new release 
> > (Ideally with my latest Ratis-PR merged).
> >
> > Chris
> >
> 

Reply via email to