Release v4.1.0

[kocio-pl]

Now that big release v4.0.0/v3.3.1 is out in the wild, we can think what do we want to land in v4.1.0, what is not ready and needs some love or should wait for v4.x.0 to not break v3 compatibility. Current changes are just small fixes, but there are some PRs waiting few weeks already.

Our roadmap is still in v3, so it would be good to update it to reflect the change.

[daganzdaanda]

Is it now possible to start working on the issues that needed hstore?
I thought there was a label once for "needs hstore" or "needs database reimport", but I seem to be wrong. Should we check all the old open issues systematically?
...
Found this list in #1504:

Keys to be added

Adding hstore will avoid the need to manually add these keys.

• emergency Add rendering for emergency=phone #318, Not rendered: ambulance_station #1160
• entrance Render names of building entrances #740, Add rendering for parking_entrance rendering #517
• golf Add rendering for golf=* #661
• addr:flats Render addr:flats or addr:unit tags like housenumber or housename #264, Render addr:flats #605
• allotments render ref numbers for allotments=plot #432
• area:highway Rendering of area:highway #180
• mountain_pass Render mountain_passes #244
• ford Add rendering for ford=yes #267
• backcountry Change or remove fill color for tourism=camp_site #1485
• memorial:type Render memorial:type=stolperstein only in z19 #1066
• lock_name Render bridge_name #828
• bridge_name Render bridge_name #828
• leaf_type Distinguish deciduous and coniferous forests #822
• int_name Rendering international names #803
• basin landuse=basin with basin=detention #709
• location Render underground buildings different #552, Pipeline should be visible #640
• protect_class Add rendering for boundary=protected_area #603
• proposed Proposed cycleways too wide #592
• information Add label for tourism=information + information=office #304, Information Boards (tourism=information) on levels <=18 #324
• network Add pictorial route shields #508
• height wind turbines: do not show minor ones at zooms 15/16/17 #1017
• generator:output:electricity wind turbines: do not show minor ones at zooms 15/16/17 #1017
• lock_name Render lock_name rather than the name of the canal #157
• bus Render public transport platforms and stops (new scheme, relation-free implementation for now) #311, Add rendering for public_transport=platform #435
• vehicle Render more specific access tags i.e. bicycle, motor_vehicle etc #214
• motor_vehicle Render more specific access tags i.e. bicycle, motor_vehicle etc #214
• motorcar Render more specific access tags i.e. bicycle, motor_vehicle etc #214

Maybe also related:

• tower/mast types Render tower:type=communication (always) #339,
• tourism=artwork details Add rendering for tourism=artwork #855,
• craft=* Add rendering for amenity=* and office=* #108,
• healthcare details Add rendering for amenity=clinic #763 Add rendering for healthcare=* tags #1981,
• leaf_type Use a random symbology for forests #1242

Also, in #70 the capacity tag is mentioned as being useful for rendering decisions.

[imagico]

As you can see in the readme we do not want to add new features for the first few releases, especially not those which cannot be backported to 3.x.

But you can and in fact are welcome to start working on things that require tags previously not available. However keep in mind that adding new feature will be evaluated carefully and critically. Tags that allow making better decisions about things we already render (like ford, basin or protect_class) are of much more interest than completely new stuff that adds additional clutter to the map.

[kocio-pl]

I'm curious how many PRs are there which satisfy v3.x compatibility and if there will be really enough of them to make "at least two MINOR releases" (as stated in README)?

[HolgerJeromin]

I thought there was a label once for "needs hstore" or "needs database reimport", but I seem to be wrong.

No, we have this milestone but it is closed:
https://github.com/gravitystorm/openstreetmap-carto/milestone/1
This was closed at the same day when #1504 was merged. I suggest reopening.

[matthijsmelissen]

No, we have this milestone but it is closed:

Perhaps because these changes no longer need a database change? :)
I reopened the milestone and slightly changed the description.

[pnorman]

Perhaps because these changes no longer need a database change? :)
I reopened the milestone and slightly changed the description.

It's kind of a misuse of a milestone to reopen with that description. A milestone is intended for a target you work towards and you can see what's left on that target by looking at its open issues.

[nebulon42]

That's correct but we never used the milestones that way. The target might have been reached, but the issues weren't solved. It's still nice to see which issues were held up because of the layout change not in effect. We could still move them to labels if that's better.

[matthijsmelissen]

It's kind of a misuse of a milestone to reopen with that description. A milestone is intended for a target you work towards and you can see what's left on that target by looking at its open issues.

Exactly - which is why the old description ('Issues that cannot be resolved without a database change') was not a very good one, as it contained only unclosable items per definition.

[kocio-pl]

I'm still a bit puzzled with v3.x compatibility claimed in our documentation. 1,5 month from v4.0.0 release (and 2 weeks from deploying it on OSMF servers) I don't remember if we have any important code to backport at all. There's also not much activity with PRs that can be backward compatible.

I think the reality is that v3.x compatibility is currently holding us back:

In order to allow time for users to reload their databases, this will be maintained until at least two MINOR releases have occurred.

With lack of backward compatible changes these users will not gain anything and it's also delaying v4.1.0 for nobody knows how long - if nobody is interested in something worth releasing as v3.4.0, it will just never gonna happen. And if there won't be v3.5.0 later, we will never release v4.2.0.

I think we should use a deadline - if there will be nothing worth tagging as next v3.x version in - let's say - a month from now, I would drop compatibility changes and stick to the v4.x.

[pnorman]

I'm still a bit puzzled with v3.x compatibility claimed in our documentation. 1,5 month from v4.0.0 release (and 2 weeks from deploying it on OSMF servers) I don't remember if we have any important code to backport at all. There's also not much activity with PRs that can be backward compatible.

We've had little activity that impacted cartography - v4.0.0...91fd10a contains a change to malls, and the rest are technical changes which don't make sense backporting (e.g. changes that result from the carto upgrade).

We have a lot of PRs open which are mergable, some of which are big cartographic changes, none of which need the schema change.

I think we should use a deadline - if there will be nothing worth tagging as next v3.x version in - let's say - a month from now, I would drop compatibility changes and stick to the v4.x.

👎

[kocio-pl]

We have a lot of PRs open which are mergable, some of which are big cartographic changes, none of which need the schema change.

Yes, I know it. But what if they will stay in this state for next few months? And how many of them should be really merged to make new release?

[imagico]

I agree with @pnorman here - there is no need to rush things and setting a time limit would not really be compatible with a volunteer project run by people in their free time.

There are tons of things that need fixing or adjustment that do not require any 4.x features. I think maybe it would even be a good idea to suggest to all contributors to reserve at least half of their work time to fixes and improvements instead of feature additions.

[matthijsmelissen]

I agree with @kocio-pl. The time limit is not for us to fix things, but for other projects to catch up with migrating their database.

[kocio-pl]

Deadlines are not about rushing anything - we can set 6 months or 2 years deadline if that's what we want. They are project management tools and help to make some reasonable plans. Lack of release holds us back and in my view this is not what makes volunteers happy and productive. For now v4-based code is not merged to the master, making a release (or dropping compatibility) will help keep things in sync.

[kocio-pl]

We've had little activity that impacted cartography - v4.0.0...91fd10a contains a change to malls, and the rest are technical changes which don't make sense backporting (e.g. changes that result from the carto upgrade).

Is this enough to release v4.1.0/v3.4.0 (or rather v3.3.2)? I like our usual scheme "release once a month" and that would be not much longer.

[pnorman]

Is this enough to release v4.1.0/v3.4.0 (or rather v3.3.2)? I like our usual scheme "release once a month" and that would be not much longer.

The only change we'd be releasing would be the malls change. Internal changes like travis, docker, utility scripts, etc are important, but not visible to users.

[kocio-pl]

That's why I think of v3.3.2 in v3 - it would fix mall issue.

Do you mean that other changes to v4 would not be released? Then this wouldn't be v4.1.0, but rather v4.0.1 and this would be no MINOR release I'm hoping for. I would like to stick to our promise if it's possible.

[pnorman]

The mall change isn't a bug fix, it's a cartographic change and needs to be in a minor release. I just don't see it worth doing a minor release when we only have one small cartographic change.

[matthijsmelissen]

The mall change is in fact a bug fix - it fixes behaviour that was not intended.

[matthijsmelissen]

@pnorman Could you remind me why we agreed to backport changes for several releases, rather than for a given timeframe? I suppose third parties relying on us would prefer the second, so they know how much time they have to chamge things. Obviously they have no idea how often we release - for all they know we might make three release the next month.

[pnorman]

Ah, we could bring it out in a patch then. I still don't consider it a particular priority.

[kocio-pl]

Hm, I'm not sure why we need to support v3 at all. OK, fixes would be nice to apply/backport, but why did we promise new features and enhancements in the old series? This is what v4 is for and they can take as much time to reload database as they want, because v3 (with fixes) isn't broken.

On the other hand we've already promised it and I look for a honest way of dealing with it without causing problems with v4 development.

[matthijsmelissen]

Hm, I'm not sure why we need to support v3 at all. OK, fixes would be nice to apply/backport, but why did we promise new features and enhancements in the old series? This is what v4 is for and they can take as much time to reload database as they want, because v3 (with fixes) isn't broken.

👍

[kocio-pl]

I had the idea to ask people directly about v3 series termination on both Talk and Dev lists. First response is here:

https://lists.openstreetmap.org/pipermail/dev/2017-July/029963.html

This user would not use v4 no matter how long time he has for transition, because he uses it also for other styles and has no place (=money) for second db. Is it possible to use v4-style database for v3 code somehow - for example with views?

[kocio-pl]

After 2 days nobody has spoken against terminating v3 series now, so I guess we can decide more freely, but it seems that we don't have to break the plan.

We could soon release v3.4.0 (along with v4.1.0) with:

Minor features:

• "New version of get-shapefiles.py" (to be backported)
• "Switch forest pattern to SVG" (to be backported)
• "Switch quarry pattern to SVG" (to be backported)
• "Switch scrub pattern to SVG" (to be backported)

Bugfixes:

• "Updating install documentation for manual shapefiles" (already backported)
• "Don't render malls as dots" (to be backported)

There are also minor features which wait for master merging (#2662, #2699, #2700) and could also be backported if they are OK.

Maybe midzoom PR (or some parts of it) will be ready to be backported to v3.5.0. Then we could go with merging v4-only code.

What's your opinion?

[matthijsmelissen]

I prefer not having to support two versions.

[kocio-pl]

So what's your plan? Wait few more days if anybody will react, and if not, just abandon v3 (with fixing README and special release message, of course) and release v4.1.0 more or less as it is?

[kocio-pl]

@math1985 I think the time is up to decide and we can safely discontinue v3 right now. It looks like users don't care, since there were no more responses to my call.

[pnorman]

If we're releasing v4.1.0 more or less as-is, why are we not also doing that for v3.4.0?

[kocio-pl]

For me that would be no problem to release as many v3 versions as you like, as long as I don't have to do it. I just don't want it to block v4 code merging and releases.

[kocio-pl]

New release is out now:

• http://www.openstreetmap.org/user/kocio/diary/41976
• New openstreetmap-carto release, v4.1.0 openstreetmap/chef#125

[kocio-pl]

There's a problem with deploying this version on OSM servers:

openstreetmap/chef#125 (comment)

It works with my Kosmtik however, so I don't understand what could be wrong.