Daniel wrote:
Frank-Rainer Grahl wrote on 8/05/2020 8:18 PM:
<Snip>
Basically only the browser works right in 2.57. Various problems with the
other components. Usually use it only when I encounter a web site broken in
2.53 to check, when I find some time for a few 2.57 fixes or test 2.53 to
2.57 ports.
FRG
Frank-Rainer, If you don't mind, what is the sequence used when producing
newer versions??
Focus is on 2.53.x
We do patches with fixes or enhancements which go into the unofficial patch
repo when the patch author thinks they are ready for testing. Asking for
official review should be done at this time too or a bit later. Some are work
in progress still ok but missing a few thing like proper styling styling. Put
in for general testing but not into the official versions. You cna see this
with the different loading indicators in Bills build or the floating delete
button in front of a receipient in mail /news (port of a TB bug lack styling).
Bill picks up the patch queues and so his builds are bleeding edge. But we use
builds done with this patches ourselves so really bad changes only go into
now and then and are usually quickly spotted. One of the reason you should
always keep you last working version.
When patches are reviewed they will be uplifted to 2.57 and checked into
comm-central. Some even earlier into 2.57 if they need a bigger modification
because of changes in the Gecko backend.
We plan to do 2.53.x Betas every 4-6 weeks so once we think that a patch level
is stable we strip out work in progress fixes for it update the official
gitlab repos and do a Beta. Only selected fixes or security backports then go
into this beta branch leading to the general release.
Bills builds switch to a higher version when we cut the beta and so it goes on.
2.57 will become ready over time. When it is we will switch the cycle over to
it.
Fixing up comm-central later might be a treat because of all the removals and
changes. Best we could do right now is done. Will only happen if we can retain
the look and feel plust most of the functionality from current SeaMonkey.
Probably needs more devs so don't expect it soon.
But everything fixed for 2.53 will go into the later releases and comm-central
will be kept building even with its own fixes just for this.
In my little bit I knowledge, I would have thought one version was basically
an improvement on the previous version, e.g.
1. Version ! of a program is produced and distributed.
2. Users of Version 1 find some problems with that version.
3. Version 2 includes some corrections (but code basically the same) and
released.
4. Users of Version 2 find some problems
5. Version 3 includes some corrections (but code basically the same) and
released.
etc, etc, etc.
Basically, once a version is "Out the door", all work on it ceases and full
resources are dedicated to production of the Newer, Improved version. Well,
O.K., maybe if there is a complete change of coding there might be "Spill"
version of the already "Out the door", 'current' version, but nothing big!
With a small'ish workforce of Volunteers, I would think this model might make
best use of the limited resources! *IMHO* of course. ;-)
But what would I know?? ;-P Not much!
It is basically done like this but on the 2.53 branch. Also backporting is
done left and right whenever possible to get newer features and security
updates into 2.53 and 2.57. 2.53.3 has many many media updates in paving the
road for AV1 and webp support in a later release for example.
FRG
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
