Re: Problem "Stable" is not stable

[Stéphane Aulery <lkppo@xxxxxxx>]

Hello,

Warning: this is a rather long message in which I try to understand the 
real situation of Gambas, the means and aspirations of its developers, 
and draw on my experience after 10 years of developing the free software 
WIKINDX.

-------------------------------------------------------------

The whole of Gambas is developed frontally. In my opinion the best is to 
divide and conquer and do dogfooding (this last thing is already applied 
by Benoît).

Divide Gambas into three or four layers based on importance, 
dependencies between components and automatic testability, and apply 
adapted release cycles from longest to shortest. This means that apart 
from fixes, you have to develop from the bottom up by applying a roadmap 
and/or separate development between teams.

- The core / language (interpreter, compiler, archiver, and scripter): 
with a real release strategy where minor versions are published for the 
sole purpose of fixing, only one major version. With a small team it is 
unrealistic to maintain more than one version in the long term in 
addition to the trunk.
- A library of standard components, included with the core/language, the 
most important and testable written for a major version of the core 
(probably those that Benoît uses for his work).
- The IDE and the components that are essential to him : own version and 
release cycle, target previous parts.
- The other components: each has its own version and release cycle.

-------------------------------------------------------------

Is there a roadmap?

How many active developers are there and for which parts?

Is there at least one developer and testers interested in release 
management instead of writing features?

Is there a dependency system between the language version and the 
components, and for the components between them?

Is there a distinction between officially maintained components and 
third-party components?

-------------------------------------------------------------

That said, with very few developers, the best thing is perhaps to divide 
in two: what is essential to the language, the rest of the components 
and software.

What is essential following a long cycle with an X.Y.Z scheme and the 
rest a rapid development based on the trunk and an 
X-YYYMMJJ-.build_number scheme which openly shows the less stable part.

Maybe the site trunkbaseddevelopment.com [1] can help you organize 
releases with a small development team.

5 days of testing is an eternity for a solo professional developer but 
for a hobbyist or a team it is far from enough. 1 week seems the bare 
minimum in my opinion and even rather 2 weeks.

-------------------------------------------------------------

For WIKINDX, a software that I develop in pairs, I only maintain one 
major version in addition to the development version. To publish it I 
apply a RC (Release Candidate) system like the development of the Linux 
kernel [2]. We alternate between developing features following a roadmap 
and RCs to test in depth, and debug the final version. We chose this 
approach after a long observation time because:
- We are only 2 developers
- We only have one non-developer tester
- Over time we have gauged that we do not have the capacity to release 
more than two major versions by year. If we try to go faster we 
introduce more bugs than we fix.
- With a roadmap we can focus on the most important things, choose our 
effort, balance between adding features, polishing, testing, 
maintenance, better coordinate with other people.

I think that the solution chosen must be adopted according to the real 
capacities of the team, the nature of the software and its use, the 
users and external contributions.

[1] https://trunkbaseddevelopment.com/
[2] https://wikindx.sourceforge.io/web/trunk/contributing/coding/

Regards,

--
Stéphane Aulery