> Do we want to adopt that?
Yes this is what we agreed on.
> Oh the reason for 8.x to 9.0 was a sort of potential
"incompatibility": We changed the version number because the license
begins to change from BSD to Apache. That could be considered
"incompatible" to some users.
I'd also like to add
On Sun, Sep 13, 2020 at 6:40 PM Gregory Nutt wrote:
> Going from 8.x to 9.0 did not follow these rules. There was not
> particular incompatibility at all. The major number changed only
> because it was the first Apache release. Other people have suggested
> boosting the major number to celebrat
On Sun, Sep 13, 2020 at 6:40 PM Gregory Nutt wrote:
>
> > I've been assiging various PRs from both repos to 10.0 milestone.
> > Please also see if you think not assigned ones are to be surely included
> > and assign them. I've not done this with issues as many are old ones
> > for which no PR was
The numbering you mention gives the same expectation to me.
Maybe we can hold off deciding the number until we build the list
of changes. This way we can know if there are indeed breaking changes.
Best,
Matias
On Sun, Sep 13, 2020, at 19:40, Gregory Nutt wrote:
>
> > I've been assiging various P
I've been assiging various PRs from both repos to 10.0 milestone.
Please also see if you think not assigned ones are to be surely included
and assign them. I've not done this with issues as many are old ones
for which no PR was proposed.
Regarding bumping release: I think we had many major cha
>
> I think it's about time we started planning for the next release. We
> had a talk the other day about the incompatibility of certain changes
> with earlier releases and if we should bump the major number. I guess
> the general consensus was to *not* do that and release a 9.
I've been checking the last release's date this morning.
I think it's about time we started planning for the next release. We
had a talk the other day about the incompatibility of certain changes
with earlier releases and if we should bump the major number. I guess
the general c
been many big changes since the last release including work
> focused on reducing memory footprint, a major overhaul of the
> documentation, and countless other things.
>
> We should get the next release started sometime soon. Is there anything in
> particular that we should wait on
We can assign issues/PRs to the next release milestone to track things we don't
want
to leave out in next release. We should categorize outstanding bugs to be
included.
In my case I would like to include the build fix I have in PRs, for example.
Another thing I'm
thinking on is
Hi folks,
There have been many big changes since the last release including work
focused on reducing memory footprint, a major overhaul of the
documentation, and countless other things.
We should get the next release started sometime soon. Is there anything in
particular that we should wait on
10 matches
Mail list logo
