github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #291] When should a new release be drafted? #233

New issue

Open

opened 2026-05-05 05:45:01 -06:00 by gitea-mirror · 12 comments

gitea-mirror commented

2026-05-05 05:45:01 -06:00

Owner

Originally created by @AdrianKoshka on GitHub (Apr 17, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/291

Originally assigned to: @p12tic, @AdrianKoshka on GitHub.

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.

Originally created by @AdrianKoshka on GitHub (Apr 17, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/291 Originally assigned to: @p12tic, @AdrianKoshka on GitHub. 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.

gitea-mirror added the

help wanted

installer/package

labels 2026-05-05 05:45:01 -06:00

gitea-mirror commented

2026-05-05 05:45:04 -06:00

Author

Owner

@p12tic commented on GitHub (Apr 19, 2019):

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.

@p12tic commented on GitHub (Apr 19, 2019): 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.

gitea-mirror commented

2026-05-05 05:45:07 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 19, 2019):

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

@AdrianKoshka commented on GitHub (Apr 19, 2019): I haven't heard from them. I know Azure pipelines was recently suggested as a wholesale solution to building on all platforms iirc (#250).

gitea-mirror commented

2026-05-05 05:45:10 -06:00

Author

Owner

@p12tic commented on GitHub (Apr 19, 2019):

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

@p12tic commented on GitHub (Apr 19, 2019): Do you think it would be appropriate to walk around the lack of communication in this way? It was their project after all :-)

gitea-mirror commented

2026-05-05 05:45:11 -06:00

Author

Owner

@p12tic commented on GitHub (Apr 19, 2019):

I agree that Azure pipelines is a potential solution.

@p12tic commented on GitHub (Apr 19, 2019): I agree that Azure pipelines is a potential solution.

gitea-mirror commented

2026-05-05 05:45:14 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 19, 2019):

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.

@AdrianKoshka commented on GitHub (Apr 19, 2019): > 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.

gitea-mirror commented

2026-05-05 05:45:16 -06:00

Author

Owner

@theinfinitypoint commented on GitHub (Apr 21, 2019):

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!

@theinfinitypoint commented on GitHub (Apr 21, 2019): 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!

gitea-mirror commented

2026-05-05 05:45:18 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Apr 21, 2019):

hoping there would be an update

Here you go (for windows)

@AdrianKoshka commented on GitHub (Apr 21, 2019): > hoping there would be an update [Here you go (for windows)](https://github.com/debauchee/barrier/releases/tag/v2.1.2)

gitea-mirror commented

2026-05-05 05:45:20 -06:00

Author

Owner

@rahuljawale commented on GitHub (May 14, 2019):

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.

@rahuljawale commented on GitHub (May 14, 2019): 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.

gitea-mirror commented

2026-05-05 05:45:23 -06:00

Author

Owner

@TafThorne commented on GitHub (May 15, 2019):

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?

@TafThorne commented on GitHub (May 15, 2019): 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.<something> for the time being?

gitea-mirror commented

2026-05-05 05:45:26 -06:00

Author

Owner

@rahuljawale commented on GitHub (May 15, 2019):

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.

@rahuljawale commented on GitHub (May 15, 2019): _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.

gitea-mirror commented

2026-05-05 05:45:29 -06:00

Author

Owner

@p12tic commented on GitHub (May 15, 2019):

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.

@p12tic commented on GitHub (May 15, 2019): 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](https://semver.org/) makes sense in this case.

gitea-mirror commented

2026-05-05 05:45:31 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (May 15, 2019):

I agree with @rahuljawale and @p12tic.

@AdrianKoshka commented on GitHub (May 15, 2019): I agree with @rahuljawale and @p12tic.