Barrier: When should a new release be drafted?

[AdrianKoshka]

I've been pulling in a number of PRs, and at some point, I know we should make another release. I just don't know when that should be.

[p12tic]

I think it's important to figure out the situation with building the release binaries in some public and reproducible way on Windows. I haven't been to IRC lately, has @walker0643 replied to our questions and suggestions? I understand that he probably does not have much time, if any, to dedicate to the project, so we should look into solutions that don't require that.

[AdrianKoshka]

I haven't heard from them. I know Azure pipelines was recently suggested as a wholesale solution to building on all platforms iirc (#250).

[p12tic]

Do you think it would be appropriate to walk around the lack of communication in this way? It was their project after all :-)

[p12tic]

I agree that Azure pipelines is a potential solution.

[AdrianKoshka]

Do you think it would be appropriate to walk around the lack of communication in this way? It was their project after all :-)

I don't know...tbh. Though, I do know, not having access to repo and organization settings will only increasingly get in the way of any progress.

[theinfinitypoint]

If it means anything, I am a user and would like to get at new Windows and OSX binary to use. There were some bugs I brought up that have since (supposedly) been fixed and I'd like to start using this program again. I've been waiting since last August hoping there would be an update. Thanks!

[AdrianKoshka]

hoping there would be an update

Here you go (for windows)

[rahuljawale]

I would say that let's make quarterly releases. Easy to track and plan and the dates don't depend on anybody. Quarterly releases could be minor releases or point releases. And by the end of the year a everything rolls up into a major release.

[TafThorne]

The words major and minor do not mean much out in the world. If we are going to go with timed releases we may as well go with year ones as well. 1.X is just as meaningless as 1.2019.01, 1.2019.04...

Unless we are going to commit to 1.x being Synergy compatible and only guarantee that 2019 (or 19 or 2.19 or...) release work within themselves (and possibly with 2018?).
Do we need to change the network protocol at the moment or could we stick with everything being 1. for the time being?

[rahuljawale]

_My $0.2 ,_

Major and minor release do actually have significance. IMO, major releases carry breaking changes or design overhauls or new features. Minor releases are mainly patches or bug fixes.

Considering that this is a community driven effort, and most of the contributors have their day jobs and families to take care of, it might be too much to ask for a major release every quarter. At the same time by having a time bound (minor) release every quarter might just keep all of us on track to deliver patches on time. That was my thought for suggesting as such.

Again, this is my personal opinion, based on my professional experience and my understanding of software development process.

[p12tic]

My agree with @rahuljawale. All Barrier developers contribute bugfixes or features inconsistently. Time-based releases fit well for established projects when you have a team of, say, 10 developers and thus there's certainty that there will be roughly 30 man-months worth of work every quarter. In the case of Barrier there will be quarters when there's little done and there will be quarters when more than one major feature will land. Thus I think semantic versioning makes sense in this case.

[AdrianKoshka]

I agree with @rahuljawale and @p12tic.