Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release v4.1.0 #2666

Closed
kocio-pl opened this issue Jun 30, 2017 · 32 comments
Closed

Release v4.1.0 #2666

kocio-pl opened this issue Jun 30, 2017 · 32 comments
Labels

Comments

@kocio-pl
Copy link
Collaborator

kocio-pl commented Jun 30, 2017

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
Copy link

daganzdaanda commented Jul 3, 2017

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
Copy link
Collaborator

imagico commented Jul 3, 2017

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
Copy link
Collaborator Author

kocio-pl commented Jul 4, 2017

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
Copy link
Contributor

HolgerJeromin commented Jul 4, 2017

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
Copy link
Collaborator

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
Copy link
Collaborator

pnorman commented Jul 4, 2017

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
Copy link
Contributor

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
Copy link
Collaborator

matthijsmelissen commented Jul 4, 2017

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
Copy link
Collaborator Author

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
Copy link
Collaborator

pnorman commented Jul 10, 2017

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
Copy link
Collaborator Author

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
Copy link
Collaborator

imagico commented Jul 10, 2017

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
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator

pnorman commented Jul 10, 2017

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
Copy link
Collaborator Author

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
Copy link
Collaborator

pnorman commented Jul 10, 2017

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
Copy link
Collaborator

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

@matthijsmelissen
Copy link
Collaborator

@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
Copy link
Collaborator

pnorman commented Jul 10, 2017

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

@kocio-pl
Copy link
Collaborator Author

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
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

kocio-pl commented Jul 23, 2017

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
Copy link
Collaborator

I prefer not having to support two versions.

@kocio-pl
Copy link
Collaborator Author

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
Copy link
Collaborator Author

kocio-pl commented Jul 27, 2017

@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
Copy link
Collaborator

pnorman commented Jul 28, 2017

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

@kocio-pl
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants