<< Firebug 1.5 available for SeaMonkey 2.0! | The roads I take... | Integration eines Magento-2-Webshops mit FreeFinance und selbstgebautem Warenmanagement >>

SeaMonkey 2.1 planning

Now that our last stable release has been shipped, the first updates have been done to make it even more solid, and the holidays have passed, it's time to start concentrating on our next feature release a bit more.
This includes trying to come up with some kind of plans, as we've seen in the quite long SeaMonkey 2.0 development period that we only get good at progress when we have good plans for what we want to do and even when we want to have it done.

So, there are a number of things we know about this upcoming release already:
From how I know our work flow, and where we stand right now, i.e. completely at the beginning of 2.1 work, I estimate the earliest possible time we could stabilize for a release would be in June or July of this year - on the other hand, we should not take longer than a year after 2.0 to release, as we really need to show that we are more active that ever and that SeaMonkey is not a dying product but going quite strong. It's better to release more often in smaller steps and put off some work to the next release than to make the impression that nothing is going on and lose people to Firefox, Thunderbird, or Opera.
Some point of insecurity in our planning is that the Mozilla platform doesn't have any clear roadmap for 2010 or even the next months as of now. Originally, there was a plan to release 1.9.3 in summer, but Firefox developers feel that too frequent updates can be painful for add-on users and authors and wonder if and which features from development they can backport to the stable 1.9.2 series instead. A summer platform release would probably fit our release plans very well, but from where we are now, we can't count on that.

Because of that, we need to see that we have our code compatible with 1.9.2 and 1.9.3 at the same time, so we can jump either way depending on where the platform plans manifest themselves. I guess we can keep that up for a few weeks, but as soon as we come to an alpha, we at least need to pronounce one tree to be official. Given our lack of build machines, we can only run tests on 1.9.1 right now and only do nightlies for one tree next to 1.9.1, but I hope that will change (I did set up some experimental build trees for 1.9.2 now, at least, but they only do "hourly" builds, which take up less time on the machines).

In any case, now is the right time to really start attacking all the things we want to have implemented in a SeaMonkey 2.1 release, and help from everyone is highly recommended!
Also, please make sure all regressions from 2.0 to current trunk nightlies are filed in Bugzilla, marked as regressions, and possibly at least nominated for blocking-seamonkey2.1a1 so that we can make sure we know where we are for eventually shipping that beast.

We will want to have at least one alpha and one beta, which 6-8 weeks spacing between those and from the last beta to release, so you can easily see how we need to come near to having real plans in our minds.

What opinions does the community have on that? What can you do to help us reach a good and possibly even better release than the last one?
Remember, this community does not work by telling others what to do (not even I or the SeaMonkey Council can do that), but by standing up, taking matters into your own hands and working together for a really valuable community-driven SeaMonkey product.
So what can you do, can you work with what I writing about here? How can plans be made to accommodate your work better?

Entry written by KaiRo and posted on January 21st, 2010 14:46 | Tags: Mozilla, SeaMonkey, SeaMonkey 2.1 | 12 comments


  • Home of KaiRo: Weekly Status Report, W03/2010 (Pingback)
  • Comments

    Pages (2): [1] 2 >| (Entry 1-10/12)


    Alfred Kayser

    from Netherlands

    Jump to 1.9.3
    Just jump to 1.9.3!
    Don't make it difficult by doing interim stuff in 1.9.2.
    Just keep 2.0.x maintenance releases for stability/security only.
    2010-01-21 16:08

    Tony Mechelynck

    from Brussels, Belgium

    Maybe just for the sake of playing devil's advocate compared to the previous comment, I'd say: Keep It Safe and Stable.

    Some Firefox releases in the past (such as 3.5) wanted to introduce too many features too fast, and as a result they were not adequately tested and therefore buggy and even crashy. SeaMonkey 2, OTOH, always impressed me by its stability, starting right when Suiterunner still called itself "SeaMonkey 1.5a" and had two sets of Preferences windows which changed almost daily according to which ones were ported from xpfe to Toolkit.

    Don't let go of that stability for the sake of new features. Any features which aren't yet 100% ready for Sm 2.1.0 will get into 2.1.5 or 2.2 — I'd say time plays in our favour. After all, a crash in Firefox leaves Thunderbird up, but a crash in the SeaMonkey browser also brings down MailNews, so the Suite concept has more need for stability than the "separate applications" concept.
    2010-01-22 01:24

    Justin Wood (Callek)

    To me, the affect of stability was helped by both us always making sure we were dogfoodable and mozilla with its new testing infra and us even taking advantage of it, and making sure things did not break THEM based on OUR settings, or fixing THEM when our settings exposed a bug.

    We even had/have our own testing infra (and TB devs even instituted a stricter testing infra for their own patches now).

    This should ensure that the stability doesn't waver below what the "post suiterunner" stability was.

    That said, my personal opinion is to keep 2.1 working for 1.9.2 and 1.9.3 until we know the timeline of 1.9.3's next release. Once we know that we can make a final decision. and if we don't know the timeline when we get closer to our planned release date we can release off 1.9.2 and be happy that we still met our goals.

    The pain point[s] would be to keep 1.9.3 working through all that, and whenever TB decides we need to cut to c-c branch... But we can work around that.

    My personal desires for SM2.next is to define the "key features we want to take" ++ "extra features would be nice" independent of what 1.9.2/1.9.3 brings. This way we can be sure to have an iterative experience for our users, beyond just a Gecko update.

    The exact branch is a seperate issue that is relatively easy to tackle.
    2010-01-22 07:57


    from paris

    publish x86_64 release build
    Please make x86_64 bits as a standard platform for release too. Only 32bits are available for release whereas x86_64 is only available for nightly or pre builds.
    2010-01-22 14:15


    from the US

    It'll be nice to try out 2.1 when it's available, just to see if it's fixed any of 2.0.x's problems. Personally, I'm through with testing 2.0.x and am going to continue using 1.1.x for the time being, but I'm willing to give 2.1 a shot.
    2010-01-22 17:25


    from Ru

    What about saving pages with all CSS and images in SM 2.1? :D

    And it would be great to include option to disable download error dialogs.
    1-30 dialogs per page for half of all pages force me to continue to use SM 1 as main browser and SM 2 as a second.
    (I block images in AdBlock Plus and save pages offline)
    2010-01-22 18:18


    I think that if you want to continue with Gecko 1.9.3,
    you should release a stable release with Gecko 1.9.2 (which should be more easy as Gecko 1.9.3 was already released).
    it may include less SM improvements, but it'll be better if there will be SM stable version with the performance improvements of Gecko 1.9.2
    2010-01-24 19:35


    from Brno

    I would ask for x64 version. Also kind of calendar alternative would be quite useful. Possible a kind of a plugin-application for gmail to the Seamonkey suite. And one thing, it would be quite nice to make faster the closing of the Seamonkey. Sometimes I close SM and after few minutes when I try to open it, it says, that it is still running.
    Anyway I am more for good stability more then for new features. Keep up the good work! :)
    2010-01-26 23:47


    from Rusiia

    Scrollable tabs
    Personally from user's perspective I strongly support Kairo's vision of the suite's future as the ability to use tabs instead of windows for all Seamonkey components and plug-ins (mail, calendar, preferences, etc.).
    It's very important for this purpose to improve the tabs functionality - to make them scrollable so all hidden tabs (as the result of overflow while opening numerous tabs) could be reached easily. I vote for the sooner new tabs functionality implementation as a priority for new Seamonkey releases.
    And many thanks for all great work done for developing and supporting the nice suite.
    2010-01-31 09:44


    from In my computer

    Personas for Sea Monkey
    I would like to see personas developed for Sea Monkey 2.1. I've tried a few of the themes that are available for Sea Monkey and don't really like any of them very much. I think a persona for Sea Monkey would be AWESOME.
    2010-02-18 18:35

    Pages (2): [1] 2 >| (Entry 1-10/12)

    Add comment