search

gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.54k stars 823 forks source link

Release v4.1.0 #2666

Closed kocio-pl closed 7 years ago

kocio-pl commented 7 years ago

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 commented 7 years ago

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.

Maybe also related:

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

imagico commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 - https://github.com/gravitystorm/openstreetmap-carto/compare/v4.0.0...91fd10a892df6db834212bd9f6741266133275f2 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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

matthijsmelissen commented 7 years ago

@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 commented 7 years ago

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

kocio-pl commented 7 years ago

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 commented 7 years ago

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.

:+1:

kocio-pl commented 7 years ago

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 commented 7 years ago

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:

Bugfixes:

There are also minor features which wait for master merging (https://github.com/gravitystorm/openstreetmap-carto/pull/2662, https://github.com/gravitystorm/openstreetmap-carto/pull/2699, https://github.com/gravitystorm/openstreetmap-carto/pull/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 commented 7 years ago

I prefer not having to support two versions.

kocio-pl commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

New release is out now:

kocio-pl commented 7 years ago

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

https://github.com/openstreetmap/chef/issues/125#issuecomment-318937103

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