Frank-Rainer Grahl wrote on 9/05/2020 8:55 PM:
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
Thanks Frank-Rainer!
--
Daniel
Win7 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0)
Gecko/20100101 SeaMonkey/2.49.5 Build identifier: 20190609032134
Linux User agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0)
Gecko/20100101 SeaMonkey/2.49.1 Build identifier: 20171015235623
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey
