Hi folks,
Today, when we do a major release (0.9.x, 0.10.x, ...), we create a
release branch.
Then, we do RCs on these release branches.
The three main reasons for that are:
1. We can create several RCs from a release branch (and it happens
often especially during incubation)
2. As a release vote
I think frequency is a hugely important goal, behind perhaps only accuracy
(if I see an annotation or a lack of one, can I trust it?).
The largest group of parameters we currently have is certainly
non-annotated arguments, no? And those arguments are currently presumed
nullable?
--EM
On Mon, Jun
Hi all,
> So now, the onus is on me, as the developer to write [...]
But this remark is valid both ways, right? If the default is non-null
and my method can return null, the onus is on me to annotate it with
@Nullable; but if the default is nullable and my method cannot return
null, then the onus
The refactor makes sense to me as well, Thanks Yufei !
persistence/
├── eclipselink/
├── relational-jdbc/
├── mongodb/
└── .../
Best,
Prashant Singh
On Mon, Jun 2, 2025 at 1:23 AM Pierre Laporte wrote:
> Could you add a README file at the root of the `persistence/` directory so
> that it is cle
After the refactor, there is a top level directory named "persistence",
which holds two implementations -- EclipseLink and JDBC. I think it makes
sense to hold more persistence impl. in the future in parallel with them
like the following example shows. WDYT?
I agree with that proposal.
However,
On Thu, May 29, 2025 at 7:40 PM Yufei Gu wrote:
> I'm supportive if it adds value to both Polaris devs and users.
Ok thanks, I am glad we have agreement on the initiative, even if we still
have to discuss the implementation details.
But, I don't think the Polaris project is in a position to pr
+1, Agree with running this only on main
On Mon, Jun 2, 2025 at 11:22 AM Eric Maynard
wrote:
> +1, great idea. This process change will reduce noise in the repo as we add
> more releases, and it also aligns more closely with the idea of a release
> as a stable snapshot of the code at some point
>
> Could you add a README file at the root of the `persistence/` directory so
> that it is clear that eclipselink is an exception to the new structure?
Good point! As an alternative, we could also explain it in a README of the
EclipseLink module. Let's do that in a follow-up.
we have "api", "com
Hi folks,
I’ve started a draft of the 1.0 release notes that lists everything we’ve
shipped since *0.9.0*. It already covers the roadmap items, but we’ve
delivered a *lot* more than that—new features, performance wins, bug fixes,
and polish that deserve to be spotlighted.
*What I need from you*
+1, great idea. This process change will reduce noise in the repo as we add
more releases, and it also aligns more closely with the idea of a release
as a stable snapshot of the code at some point in time -- including the
dependencies as they were at that time.
--EM
On Mon, Jun 2, 2025 at 9:14 A
Hi All,
I've just added [1775] to the list of 1.0 blockers. My rationale:
* As discussed in [1758], current configuration lookup methods have a
certain API skew.
Some methods have PolarisCallContext parameters, others
RealmContext. PolarisCallContext implies a certain realm ID (e.g. it
includes
Let's clarify what we talk about when we say "presumed" about non-annotated
arguments - my opinion below.
>From my POV, for human developers presuming @Nonnull would be natural. I
certainly do that (unless javadoc is explicit). The "natural" aspect, IMHO,
comes from the fact that returning a value
Hi Team,
In order to get rid of the usage of CallContext.getCurrentContext() call in
the getConfiguration implementation of DefaultConfigurationStore, we did
one attempt leverage CDI to inject request scoped RealmContext into the
application scoped DefaultConfigurationStore.
Commit:
https://github
Hi
I think the structure proposed by Yufei makes sense. It's aligned and
similar to what I'm proposing in https://github.com/apache/polaris/pull/1695
by renaming the quarkus folder as runtime folder.
For persistence, I think it makes more sense than a separate repository
because:
1. It avoids dev
Could you add a README file at the root of the `persistence/` directory so
that it is clear that eclipselink is an exception to the new structure?
Otherwise, there will be two persistence implementations in Polaris with
different package naming schemes, which can add confusion from an external
pers
This model for release branches makes sense to me.
I also support NOT running Renovate on release branches. If we need to
include dependency upgrades in another RC, I suppose we can redo the
release branch from main (or manually apply version changes)... however,
I'd expect this to be a very rare
Hi JB,
I agree that it doesn't feel safe to run Renovate on release branches
and risk dependency upgrades between release attempts. Besides, we can
always bump versions manually if needed.
So, +1 on your proposal to only run Renovate on main.
Thanks,
Alex
On Mon, Jun 2, 2025 at 5:58 PM Dmitri B
> And those arguments are currently presumed nullable?
I would rather say that the current state of the code is "undetermined
nullness".
Just one random example: PolarisCatalogHelpers [1]. This class has no
nullability annotations, yet all of the parameters without exception
are implicitly non-nu
18 matches
Mail list logo
