Release 5.0.0 and discussion

[eMerzh]

Hey, now that there are muliple person involve,

i was wondering if now is not a good time to cut a release (beta or some pre- thing)
or at least determin a good time to do that.

also, not sure what's the best channel to discuss this, github issues?

[Glandos]

I don't know if some people are still using IRC, but I've created #ihatemoney on Freenode.

EDIT: now that Freenode has been killed, the channel is registered on libera.chat.

[indatwood]

I've joined the IRC channel, let's see if there is some activity in there :-)

+1 to cut a release. I've checked the previous releases and it didn't seemed to have a beta or pre- channel, so I'm not sure how we should do it, but I believe it could be a good thing : a bunch of new features were implemented, and might break :-)

[eMerzh]

the last thing we want to get fix is the werkzeug thing.... i might have a shot at this soon.

Not a huge fan of IRC, but i'd rally to what other prefer.

[eMerzh]

now werkzeug seems to be cared for :)
we can move forward...

[zorun]

A new release would be good! 4.1.3 is now 7 months old and things changed quite a lot.

However, there are some pretty big features (such as #553), so it would be good to gain more exposure to catch remaining bugs and regressions. The IHM doc says:

Ihatemoney follows semantic versioning. So minor/patch upgrades can be done blindly.

In that case I wouldn't upgrade blindly ;) So it would be good to either go directly to 5.0 (although there are no backwards-breaking changes I think?), or introduce beta/rc releases.

[Natim]

introduce beta/rc releases.

I think going with semantic versioning is good enough. If there is a bug, people can still use the previous version in the meantime, file an issue and we will do a patch release right after. We don't need to make a complex setup here IMHO.

Release early, release often.

[zorun]

I have created a milestone to track blocking issues before 5.0.0 can be released: https://github.com/spiral-project/ihatemoney/milestone/5

In my opinion we should not merge new features before the release of 5.0.0: it already introduces many new features. We should focus on ironing out the last big issues with these features.

[zorun]

The plan is to release version 5.0.0 next Sunday (26 July), including an upcoming fix for a significant issue. The fix will also be released in stable version 4.1.5.

[zorun]

So, it turns out there were quite a lot of fixes needed, and the motivation died down after last summer.

Let's try to release before 26 July of this year ;)

[almet]

Hey, it's not clear what's the path to 5.0 now. I think we still need to address #848 and we'll be good to go. Is that okay for everyone?

[zorun]

For me #848 is not blocking, and I'm against merging anything new before 5.0.0 is out.

In short: let's release 5.0.0 now!

[almet]

Oops, sorry I'm reading this just after merging #848… Let's release!

[almet]

And, it's done!

[zorun]

Thanks a lot Alexis <3

[zorun]

@almet strange, your tags for 5.0.0 and 5.0.1 are not in the master branch, is it intended?

[almet]

I'm not sure :-) Should it be on master? I usually create a branch to prepare everything and run make release from there, which probably explains why it's not based on the master branch.

How would you do it?

[zorun]

The same with make release, but on the master branch :) I would find it much less confusing.

For instance, by default, git doesn't seem to download out-of-branch tags, so they are not easily visible. Also, git describe does not work properly in this case, etc.