EOL for 3.0

[Jiří Činčura]

Hi *,

What's the official EOL for 3.0 branch?

--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/

[Dmitry Yemanov]

06.04.2024 11:22, Jiří Činčura wrote:
>
> What's the official EOL for 3.0 branch?

We don't have any official decision yet. Usually EOL is V+2 (v5 is out,
v3 gets discontinued), but migration to v4/v5 was quite slow and many
users are still running v3 and would surely appreciate bugfixes. So I'd
say we should support it at least during this year, and maybe even until
v6 is out. But this is just IMHO, other opinions are welcome.


Dmitry

[F. D.Castel]

The V+2 EOL seems to be reasonable... But only if major releases are REALLY major releases .

Trying not to hit a nerve here, but v5 should have been called v4.1 or v4.5, IMHO.

Why doesn't Firebird release minor versions more often? -- If it is a build problem, I believe Adriano has been working HARD to improve it.

Take a look at the v6 "roadmap": https://firebirdsql.org/en/roadmap-v6/

It has *A LOT* of *COMPLETED* _minor_ features. 

But they will only see the light of day 1.5 years (!!!) from now. 

Then, and ONLY THEN, the team will start to get significant feedback for them.

What is stopping the team from releasing a 5.1 now with these completed features?

P.S.: FB 4+ DataTypeCompatibility was a VERY good idea. But the releases also need to start showing up more frequently or the migration from v3 WILL be (very) slow.

[Mark Rotteveel]

On 11/05/2024 23:01, F. D.Castel wrote:
> The V+2 EOL seems to be reasonable... But only if major releases are
> REALLY major releases .
>
> Trying not to hit a nerve here, but v5 should have been called v4.1 or
> v4.5, IMHO.
>

> *Why doesn't **Firebird **release minor versions more often? *-- If it

> is a build problem, I believe Adriano has been working HARD to improve it.

We have decided to follow the trend here: most database systems (and
other projects as well) don't do minor versions.

Personally, I think the project should release point releases (bugfix
releases) more often than they're currently done.

> Take a look at the v6 "roadmap": https://firebirdsql.org/en/roadmap-v6/
>
> It has *A LOT* of *COMPLETED* _minor_ features.
>

> *But they will only see the light of day 1.5 years (!!!) from now. *

>
> Then, and ONLY THEN, the team will start to get significant feedback for
> them.
>

> *What is stopping the team from releasing a 5.1 now with these completed
> features?*

Why not just ask if a Firebird 6 can be released now? Why would it need
to be named Firebird 5.1?

> P.S.: FB 4+ DataTypeCompatibility was a VERY good idea. But the releases
> also need to start showing up more frequently or the migration from v3
> WILL be (very) slow.

How will more frequent release increase the progress from migrating from
v3 to newer versions? The Firebird community seems very reluctant to
upgrade, as demonstrated by a recent post from someone who is only now
starting to think about migrating away from Firebird 1.5, which had its
last release 15 years ago.

Mark
--
Mark Rotteveel

[Adriano dos Santos Fernandes]

On 11/05/2024 18:01, F. D.Castel wrote:
> The V+2 EOL seems to be reasonable... But only if major releases are
> REALLY major releases .
>
> Trying not to hit a nerve here, but v5 should have been called v4.1 or
> v4.5, IMHO.
>

> *Why doesn't **Firebird **release minor versions more often? *-- If it

> is a build problem, I believe Adriano has been working HARD to improve it.
>
>
>
> Take a look at the v6 "roadmap": https://firebirdsql.org/en/roadmap-v6/
>
> It has *A LOT* of *COMPLETED* _minor_ features. 
>

> *But they will only see the light of day 1.5 years (!!!) from now. *

>
> Then, and ONLY THEN, the team will start to get significant feedback for
> them.
>

> *What is stopping the team from releasing a 5.1 now with these completed
> features?*
>

First, I believe it's problematic to be strict about semantic versioning
in a DBMS.

Almost any feature possible breaks things when there are new keywords,
so it would be a major version. Note that we even had the specific case
of introduce LOCALTIME/LOCALTIMESTAMP in a patch release to make
adaptation for newer major releases easier when it made sense.

I agree we should release new potentially not-breaking new features more
often. While automated build makes this easier, it's not the only thing.
We need good documentation, and that is often done in "batches" by few
people (Mark, Dmitry) when a release is being prepared.

Here it would be valuable if the community is more active. They could
contribute adapting "raw" developers documentation in final docs, also
testing the snapshots in relation to that docs. Usually this is the
entry point for people in open source projects, but we lack this help here.

Another point would be to have limited set of these new "minor" releases
or otherwise nobody is going to update to major (with potentially
breaking, new ODS) ones.

Also, if we adopt X.5 versions (or even X + 1) with these "minor"
features, it should mean we would need to deprecate X.Y.Z+1 (patch
releases) earlier.


Adriano