You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any chance of a new release to pick up the latest fixes for version 2? Especially to include 999f153 which is the main problem we see from time to time.
The mentioned commit is over 2.5 years old, if your favorite distribution did not pick that up meanwhile, that is not really csync2's fault ;-)
But okay, I'll add a release tag for 2.1 within the next days, pretending that would carry some meaning. Because, why not. Thank you for the friendly reminder!
if your favorite distribution did not pick that up meanwhile, that is not really csync2's fault ;-)
No, it is. All distributions normally package released software versions, not an arbitrary commit in the development branch. There are many good reasons for this. The last csync2 release is already 11 years old.
Not bothering to simply tag a release has hurt this project's visibility. Because of this, it has dropped off EPEL, which is the main repo that enterprise sysadmins use to install packaged, and supported software that isn't directly supported by Red Hat. Most have a policy to only install packaged software to save time, and for the reason that they will receive updates during regular patching, and releases tagged by the project's authors are an important part of that process.
When I used to work at a site that used csync2, I would have been willing to maintain the project on EPEL, but I gave up since there was no new release. There has to be a release tag to indicate when there is a minor change that can readily be updated via patching vs a major change that might break compatibility. There may need to be several tags added to represent the various milestones that have occurred since the last release tag. 🥺 🙏
Activity
lge commentedon Oct 31, 2019
The mentioned commit is over 2.5 years old, if your favorite distribution did not pick that up meanwhile, that is not really csync2's fault ;-)
But okay, I'll add a release tag for 2.1 within the next days, pretending that would carry some meaning. Because, why not. Thank you for the friendly reminder!
dannyweldon commentedon Nov 20, 2019
Thank you!
jirutka commentedon Sep 10, 2026
No, it is. All distributions normally package released software versions, not an arbitrary commit in the development branch. There are many good reasons for this. The last csync2 release is already 11 years old.
ROBERT-MCDOWELL commentedon Sep 10, 2026
and works very well...
jirutka commentedon Sep 10, 2026
Actually, it doesn’t. We had to backport several patches from master to make it work.
ROBERT-MCDOWELL commentedon Sep 10, 2026
maybe fork if your PR does not pass?
dannyweldon commentedon Sep 26, 2026
Not bothering to simply tag a release has hurt this project's visibility. Because of this, it has dropped off EPEL, which is the main repo that enterprise sysadmins use to install packaged, and supported software that isn't directly supported by Red Hat. Most have a policy to only install packaged software to save time, and for the reason that they will receive updates during regular patching, and releases tagged by the project's authors are an important part of that process.
When I used to work at a site that used csync2, I would have been willing to maintain the project on EPEL, but I gave up since there was no new release. There has to be a release tag to indicate when there is a minor change that can readily be updated via patching vs a major change that might break compatibility. There may need to be several tags added to represent the various milestones that have occurred since the last release tag. 🥺 🙏