Thanks for raising these questions!
These are all thoughts that have quite an impact on several aspects:
* Will there be 1.0.x releases?
* If so, how long will 1.0.x be maintained?
* Will 1.1 be based on 1.0 or main?
* What if we put 2.x into the mix?
There are even more "questions" to that - the combined result impacts
the name of the release branch, if it is needed, the web site and
potentially other aspects.
The "semi automated releases" draft-PR already considers different
answers to these questions. I.e. a branch is not required for a release
- release-branches and releases are orthogonal. All you technically need
for a release is a Git commit to create a release from.
On 13.06.25 01:51, Dmitri Bourlatchkov wrote:
From my POV the "release/a.b.c" pattern for release branches is
self-explanatory and has prior history in Polaris.
If the release guilde is perceived as too vague on this topic, let's update
the guide and keep the pattern.
In that regard, we may want to discuss whether to use very versions
specific branches like release/1.0.0 or use a branch per minor versions
like release/1.0.x
I'm personally fine with either approach.
Another question: shall we tag after a release is approved and remove
release branches?
From my POV doing that would make sense so as to keep the set branches lean
and clean (as discussed in a separate thread in a more general context). We
can always re-create branches for point releases from the previous release
tag. WDYT?
Cheers,
Dmitri.
On Thu, Jun 12, 2025 at 4:55 PM Yufei Gu <flyrain...@gmail.com> wrote:
Delete the branch "1.0.x".
I'm OK with the name "release/1.0.x", but I don't think the current release
guideline[1] mentioned any mandatory branch name convention. The name
"release/x.y.z" is part of an example. We should add that name convention
to the guidelines.
[1] https://polaris.apache.org/community/release-guide/
Yufei
On Thu, Jun 12, 2025 at 11:07 AM Robert Stupp <sn...@snazy.de> wrote:
Heads up: It's also documented in the release-guide via
https://github.com/apache/polaris/pull/1539, not sure you saw it. That
doc also mentions how to apply versions, create tags etc.
On 12.06.25 19:41, Yufei Gu wrote:
Thanks for the explanation. Created a new branch named "release/1.0.x"
for
the 1.0 release. I will delete "1.0.x" a bit later.
Yufei
On Thu, Jun 12, 2025 at 9:05 AM Robert Stupp <sn...@snazy.de> wrote:
Not sure whether everybody followed how the releases were crafted. We
discussed the branch naming pattern before during community sync
calls.
There's also the draft PR 485 for semi-automatic releases that relies
on
the same naming pattern. To change that, we have to have a discussion
on
dev@ first.
1695 is for me a legit 1.0-blocker, as it changes the artifact names
that users may refer to - including downloadable binary distributions.
Either we change it before 1.0 or not at all.
PR 485: https://github.com/apache/polaris/pull/485
On 12.06.25 17:48, Yufei Gu wrote:
We didn't do that for 0.9 and 0.10 releases before cutting a branch.
If
you
think that's a new process we need to follow, please open a new dev
ML
thread for discussion.
the wrong branch name
Can you explain why there is a wrong branch name?
Where is this agreement recorded?
Where is the agreement record of adding [1] as a 1.0 blocker? Can you
open
a thread for that if there is not? It seems controversial now.
[1] https://github.com/apache/polaris/pull/1695.
Yufei
On Thu, Jun 12, 2025 at 4:21 AM Jean-Baptiste Onofré <
j...@nanthrax.net>
wrote:
Hi folks
Back from the other part of the pond :)
I think we should have a clear consensus about
1.0 content. That’s why I invite everyone to flag issues and PRs
with
the
1.0-blocker label.
I propose to do a review in 24h. As soon as we don’t have any
1.0-blocker,
we are good to start rc.
We can also chat about that during the community meeting today.
If it helps, I’m happy to prepare the 1.0 rc0 (I’m doing a new pass
on
the
main branch mainly about license/notice etc).
Thanks !
Regards
JB
Le jeu. 12 juin 2025 à 10:10, Robert Stupp <sn...@snazy.de> a
écrit :
Agree with Dmitri.
Having clear discussion subjects is crucial for the community to
follow
the right threads. I think we should only get to consensus about
the
particular thread topic and nothing else.
Consensus in a community in general, at least in my opinion, is
more
than two people having the same opinion.
We should also be careful about giving everybody enough time, and
consider weekends and potentially public regional holidays.
Regarding the technical actions: The branch name doesn't comply
with
the
existing naming convention (the branch naming pattern that JB
used),
which is also required to later support semi-automatic releases
(discussed a couple months ago during a community sync call).
Considering that we do not seem to have a consensus on the content
of
the 1.0 release, there are still 1.0-blockers and the wrong branch
name,
I strongly prefer do delete that branch.
Regarding the release manager, I'm in favor of letting JB drive the
release process to ensure that things go smooth.
Related note: We already have quite a bunch of branches in the GH
repo
whose meaning is not clear to me.
Robert
On 12.06.25 00:37, Dmitri Bourlatchkov wrote:
Also the
last PPMC member's agreement on thread[1] happened 5 days ago,
which
passed
the lazy consensus window. But I agreed it's nice to conclude a
thread.
The consensus in that thread was to skip the 0.10.0 release.
From my POV an agreement to skip 0.10.0 does not mean that the
scope
for
1.0 is set and agreed upon.
What I'm asking for is proactively engaging with the community
before
executing technical actions for a new release as opposed to
informing
after
actions are taken.
[1]
https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
Thanks,
Dmitri.
On Wed, Jun 11, 2025 at 6:20 PM Yufei Gu <flyrain...@gmail.com>
wrote:
The branch name is "1.0.x".
Where is this agreement recorded?
Discussed multiple times with JB last Thursday(6/5/2025) and this
Monday(6/9/2025), we agreed to consider it as a nice-to-have
instead
of
a
blocker.
As a matter of best practice, given the previous related
discussion
thread
[1], it would have been nice to conclude it with a message about
starting
the 1.0 release process before actually cutting the branch.
We got consensus on thread[1]. The 1.0 release was also prepared
way
before
the thread. We will kick off 1.0 release even if 0.10 is not
canceled.
JB
and I discussed the parallel releasing option for both versions.
Also
the
last PPMC member's agreement on thread[1] happened 5 days ago,
which
passed
the lazy consensus window. But I agreed it's nice to conclude a
thread.
[1]
https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
Yufei
On Wed, Jun 11, 2025 at 2:33 PM Dmitri Bourlatchkov <
di...@apache.org
wrote:
I cut the 1.0.x branch yesterday morning.
As a matter of best practice, given the previous related
discussion
thread
[1], it would have been nice to conclude it with a message about
starting
the 1.0 release process before actually cutting the branch.
[1]
https://lists.apache.org/thread/8kx1mjg7hsq09z3rlmf77g4trs5p9xrh
Thanks,
Dmitri.
On Wed, Jun 11, 2025 at 4:33 PM Yufei Gu <flyrain...@gmail.com>
wrote:
Thanks everyone for the contribution. We've finally resolved
all
blockers[1]. I cut the 1.0.x branch yesterday morning. Will
only
cherry
pick bug fixes and license related commits to this branch
starting
now.
[1]. PR1695 is labeled with 1.0 blocker, but we agreed that
it's
a
best-to-have instead of a blocker per offline discussion,
https://github.com/apache/polaris/pull/1695.
Yufei
On Tue, Jun 3, 2025 at 3:21 PM Eric Maynard <
eric.w.mayn...@gmail.com
wrote:
+1 to making 801 a blocker.
Based on Alex's comments in 1799, it looks like the rotation
is
only
happening in JdbcMetastoreManagerFactory? If so, I think we
have a
very
simple fix in PR#1804 <
https://github.com/apache/polaris/pull/1804
.
--EM
--
Robert Stupp
@snazy
--
Robert Stupp
@snazy
--
Robert Stupp
@snazy
--
Robert Stupp
@snazy
