Next release?

[Nathan Hartman <ha...@gmail.com>]

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 before proceeding?

Cheers,
Nathan

Re: Next release?

[Abdelatif Guettouche <ab...@gmail.com>]

> 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 that before releasing 9.0 we missed 2 release cycles,
so the difference between 8.x and 9.0 was also quite large.

On Mon, Sep 14, 2020, 01:42 Nathan Hartman <ha...@gmail.com> wrote:

> On Sun, Sep 13, 2020 at 6:40 PM Gregory Nutt <sp...@gmail.com> 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 celebrate the NuttX2019 event.  The only
> > point is that we need to decide what these numbers mean and be
> consistent.
>
> 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.
>

Re: Next release?

[Nathan Hartman <ha...@gmail.com>]

On Sun, Sep 13, 2020 at 6:40 PM Gregory Nutt <sp...@gmail.com> 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 celebrate the NuttX2019 event.  The only
> point is that we need to decide what these numbers mean and be consistent.

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.

Re: Next release?

["Matias N." <ma...@imap.cc>]

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 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 changes
> > and I was under the impression that we indeed should do a major
> > bump (hence the 10.0 milestone name).
> >
> > But maybe I've read that wrong
> 
> Well, I think that the issue is that we need to decide what the major 
> release number means.  If it means that the code users have under 9.x 
> will not no longer work, it should be boosted to 10.0. Otherwise, under 
> what conditions to we boost the major revision number?
> 
> 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 celebrate the NuttX2019 event.  The only 
> point is that we need to decide what these numbers mean and be consistent.
> 
> As a user, I expect to see issues if I upgraded from (n).(x) to (n+1).0. 
> I would not expect to see issues if I upgraded from (n).(x) to 
> (n).(n+1).  What would be your expectation?
> 
> 
> 

Re: Next release?

[Nathan Hartman <ha...@gmail.com>]

On Sun, Sep 13, 2020 at 6:40 PM Gregory Nutt <sp...@gmail.com> 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 proposed.
> >
> > Regarding bumping release: I think we had many major changes
> > and I was under the impression that we indeed should do a major
> > bump (hence the 10.0 milestone name).
> >
> > But maybe I've read that wrong
>
> Well, I think that the issue is that we need to decide what the major
> release number means.  If it means that the code users have under 9.x
> will not no longer work, it should be boosted to 10.0. Otherwise, under
> what conditions to we boost the major revision number?
>
> 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 celebrate the NuttX2019 event.  The only
> point is that we need to decide what these numbers mean and be consistent.
>
> As a user, I expect to see issues if I upgraded from (n).(x) to (n+1).0.
> I would not expect to see issues if I upgraded from (n).(x) to
> (n).(n+1).  What would be your expectation?
>
>
> I think the best policy is described here:

https://semver.org/

New major version = backwards incompatible API changes.

New minor version = backwards compatible.

New patch version = bugfixes (and backwards compatible obviously)

Do we want to adopt that?

Nathan

Re: Next release?

[Gregory Nutt <sp...@gmail.com>]

> 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 changes
> and I was under the impression that we indeed should do a major
> bump (hence the 10.0 milestone name).
>
> But maybe I've read that wrong

Well, I think that the issue is that we need to decide what the major 
release number means.  If it means that the code users have under 9.x 
will not no longer work, it should be boosted to 10.0. Otherwise, under 
what conditions to we boost the major revision number?

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 celebrate the NuttX2019 event.  The only 
point is that we need to decide what these numbers mean and be consistent.

As a user, I expect to see issues if I upgraded from (n).(x) to (n+1).0. 
I would not expect to see issues if I upgraded from (n).(x) to 
(n).(n+1).  What would be your expectation?

Re: Next release?

["Matias N." <ma...@imap.cc>]

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 changes
and I was under the impression that we indeed should do a major
bump (hence the 10.0 milestone name).

But maybe I've read that wrong

Best,
Matias

On Sun, Sep 13, 2020, at 20:15, Abdelatif Guettouche wrote:
> 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 consensus was to *not* do that and release a 9.3.
> 
> In regards to what changes we would want in, I think Xiang's idle
> thread stack PR is important.
> There are also the new PRs from Matias that address some corner cases
> in the build system.
> 
> On Sun, Sep 13, 2020 at 6:04 PM Adam Feuer <ad...@starcat.io> wrote:
> >
> > Nathan,
> >
> > There's still some work needed in getting install docs working and verified
> > for a widely supported board (STM Nucleo 144 is the one we chose). It will
> > probably be done this week.
> >
> > -adam
> >
> > On Sun, Sep 13, 2020 at 9:54 AM Nathan Hartman <ha...@gmail.com>
> > wrote:
> >
> > > 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 before proceeding?
> > >
> > > Cheers,
> > > Nathan
> > >
> >
> >
> > --
> > Adam Feuer <ad...@starcat.io>
> 

Re: Next release?

[Abdelatif Guettouche <ab...@gmail.com>]

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 consensus was to *not* do that and release a 9.3.

In regards to what changes we would want in, I think Xiang's idle
thread stack PR is important.
There are also the new PRs from Matias that address some corner cases
in the build system.

On Sun, Sep 13, 2020 at 6:04 PM Adam Feuer <ad...@starcat.io> wrote:
>
> Nathan,
>
> There's still some work needed in getting install docs working and verified
> for a widely supported board (STM Nucleo 144 is the one we chose). It will
> probably be done this week.
>
> -adam
>
> On Sun, Sep 13, 2020 at 9:54 AM Nathan Hartman <ha...@gmail.com>
> wrote:
>
> > 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 before proceeding?
> >
> > Cheers,
> > Nathan
> >
>
>
> --
> Adam Feuer <ad...@starcat.io>

Re: Next release?

[Adam Feuer <ad...@starcat.io>]

Nathan,

There's still some work needed in getting install docs working and verified
for a widely supported board (STM Nucleo 144 is the one we chose). It will
probably be done this week.

-adam

On Sun, Sep 13, 2020 at 9:54 AM Nathan Hartman <ha...@gmail.com>
wrote:

> 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 before proceeding?
>
> Cheers,
> Nathan
>


-- 
Adam Feuer <ad...@starcat.io>

Re: Next release?

["Matias N." <ma...@imap.cc>]

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 having the documentation support not only latest (master) but also stable (release).
But I think this would not be a blocker.

Best,
Matias

On Sun, Sep 13, 2020, at 10:55, Nathan Hartman wrote:
> 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 before proceeding?
> 
> Cheers,
> Nathan
>