~dmbaturin/soupault

3 3

[YOUR INPUT NEEDED] Soupault 2.0 migration plan

Details
Message ID
<a064f713-2319-1045-ae23-961a52f2f3ce@baturin.org>
DKIM signature
pass
Download raw message
Hi everyone,

I've already been talking about planned incompatible changes for
soupault 2.0 release, and no one actively objected.

Now it's time to make precise migration plans.

First, a quick recap of the issues:
1. index options like index_date_selector etc. duplicate the custom
fields functionality but are less flexible than custom fields
2. settings.default_template option duplicates the functionality of
custom templates
3. breadcrumbs widget's breadcrumb_template option should better be a
template string rather than a base HTML string with implicit "a" selector

Now, we have two options.

Plan A is a flag day.
* Old options are removed immediately. Their presence is used to tell
whether a config is in the old format and needs migration.
* An automatic config syntax migration tool will be made (most likely in
form of a client-side web app).

An obvious drawback of the plan A is that it's disruptive. The advantage
is that legacy code will be gone immediately.
From my experience, few people proactively fix deprecation warnings.
Also, there are still few soupault users but new users are coming, so it
may be better to have a flag day now, when I still can work with every
user to help them migrate, if nothing else.

Plan B is gradual deprecation. Old options are mapped to new options and
glaring deprecation warnings are added.
It's less disruptive, but has its own problems. For example, if a user
has a handwritten [templates.default] and default_template in the
settings, which one should take precedence?

Myself, I'm leaning towards the plan A. I'd like to hear your opinions.
Hristos N. Triantafillou
Details
Message ID
<9cd36eb5-9115-ab18-391c-dfa916633fc2@triantafillou.us>
In-Reply-To
<a064f713-2319-1045-ae23-961a52f2f3ce@baturin.org> (view parent)
DKIM signature
missing
Download raw message
I myself strongly prefer Plan A.

It will make the transition go more smoothly, even if at first it is
more legwork, and of course it frees you from being limited by legacy
support burdens.

And last but not least: the availability of a migration tool (which I
understand is in the works) really seals the deal for me.

-Hristos

On 8/3/20 5:46 PM, Daniil Baturin wrote:
> Hi everyone,
>
> I've already been talking about planned incompatible changes for
> soupault 2.0 release, and no one actively objected.
>
> Now it's time to make precise migration plans.
>
> First, a quick recap of the issues:
> 1. index options like index_date_selector etc. duplicate the custom
> fields functionality but are less flexible than custom fields
> 2. settings.default_template option duplicates the functionality of
> custom templates
> 3. breadcrumbs widget's breadcrumb_template option should better be a
> template string rather than a base HTML string with implicit "a" selector
>
> Now, we have two options.
>
> Plan A is a flag day.
> * Old options are removed immediately. Their presence is used to tell
> whether a config is in the old format and needs migration.
> * An automatic config syntax migration tool will be made (most likely in
> form of a client-side web app).
>
> An obvious drawback of the plan A is that it's disruptive. The advantage
> is that legacy code will be gone immediately.
> From my experience, few people proactively fix deprecation warnings.
> Also, there are still few soupault users but new users are coming, so it
> may be better to have a flag day now, when I still can work with every
> user to help them migrate, if nothing else.
>
> Plan B is gradual deprecation. Old options are mapped to new options and
> glaring deprecation warnings are added.
> It's less disruptive, but has its own problems. For example, if a user
> has a handwritten [templates.default] and default_template in the
> settings, which one should take precedence?
>
> Myself, I'm leaning towards the plan A. I'd like to hear your opinions.
>
Thomas Letan
Details
Message ID
<20200804070840.i4fyktaaxhcvncsv@ideepad.localdomain>
In-Reply-To
<9cd36eb5-9115-ab18-391c-dfa916633fc2@triantafillou.us> (view parent)
DKIM signature
pass
Download raw message
> I myself strongly prefer Plan A.

I agree (and not because, afaict, I am not using the features impacted by
the breaking changes :p).

One way to proceed more smoothly could be to release beta versions?

At the very least, feel free to ping me when you have an unofficial 2.0
build to test.

Thanks for your hard work.

Best regards,
Thomas
Details
Message ID
<87k0yedaya.fsf@riseup.net>
In-Reply-To
<20200804070840.i4fyktaaxhcvncsv@ideepad.localdomain> (view parent)
DKIM signature
pass
Download raw message
Happy with plan A. This looks better for new comers.

BTW, thanks for asking

-- 
nicolas
Reply to thread Export thread (mbox)