Feature: having a LTS branch in some future #1167

Closed
opened 2025-11-02 03:51:08 -06:00 by GiteaMirror · 8 comments
Owner

Originally created by @hubyhuby on GitHub (Oct 19, 2017).

This is a a feature request.
Gitea is a quite young git code manager. Therefore it moves fast and has a release cycle as fast.
Which is super nice to see.
Also on a production perspective it is important to have a stable environment to work with.
Whenever Gitea reach a point where the feature set is acceptable, we could think of having an LTS branch, maintained 12 months for a start.

Would be super if that would happen; let say on release 1.5 in 2018 ?

Originally created by @hubyhuby on GitHub (Oct 19, 2017). This is a a feature request. Gitea is a quite young git code manager. Therefore it moves fast and has a release cycle as fast. Which is super nice to see. Also on a production perspective it is important to have a stable environment to work with. Whenever Gitea reach a point where the feature set is acceptable, we could think of having an LTS branch, maintained 12 months for a start. Would be super if that would happen; let say on release 1.5 in 2018 ?
GiteaMirror added the type/proposal label 2025-11-02 03:51:08 -06:00
Author
Owner

@OmarAssadi commented on GitHub (Oct 19, 2017):

I think the release cycle for Gitea is pretty generous—at least on par with Gitlab, if not better. But, I could definitely see a company wanting a rock-solid branch that only receives fixes instead of rolling the dice with upgrading to a feature release.

Could be nice in the future. I think there are some things that be addressed before an LTS release is considered, though. Code review is one of those.

@OmarAssadi commented on GitHub (Oct 19, 2017): I think the release cycle for Gitea is pretty generous—at least on par with Gitlab, if not better. But, I could definitely see a company wanting a rock-solid branch that only receives fixes instead of rolling the dice with upgrading to a feature release. Could be nice in the future. I think there are some things that be addressed before an LTS release is considered, though. Code review is one of those.
Author
Owner

@hubyhuby commented on GitHub (Nov 3, 2017):

Dear @54 ,
Maybe a nice thing for a start would be to have a roadmap, or a tentative of a roadmap :)
I am starting to use gitea this month for professional projects.
I think it would be reassuring to see there is a big plan (to conquer the world?). Even if we say we will start a train release cycle in 6 or 12 monthes, users will then have a big picture of what they are "jupping in".

We could choose say, a release cycle like this :
-every 6 monthes a new 1.X
-during 6 monthes 1.x.Y versions
-in parallele another 1.(X+1) branch is running

We could set this on a 3 monthes cycle aswell. Release train is a common thing those days with big projects like gitea.
We could start with 1.4 as 1.3 is already about to release ?

PS: I am not comminting myself to gitea, those are just ideas from a end user point of view.

@hubyhuby commented on GitHub (Nov 3, 2017): Dear @54 , Maybe a nice thing for a start would be to have a roadmap, or a tentative of a roadmap :) I am starting to use gitea this month for professional projects. I think it would be **reassuring** to see there is a big plan (to conquer the world?). Even if we say we will start a train release cycle in 6 or 12 monthes, users will then have a big picture of what they are "jupping in". We could choose say, a release cycle like this : -**every 6 monthes a new 1.X** -during 6 monthes 1.x.Y versions -in parallele another 1.(X+1) branch is running We could set this on a 3 monthes cycle aswell. Release train is a common thing those days with big projects like gitea. We could start with 1.4 as 1.3 is already about to release ? PS: I am not comminting myself to gitea, those are just ideas from a end user point of view.
Author
Owner

@bkcsoft commented on GitHub (Nov 3, 2017):

We do have a release train, though it was slightly delayed for v1.2... a new Minor every 2 months, RC1 created 1 month into the release. No backports to lesser Minors, but backports (or "pick-into-stable") from master=>release/v1.X. And no LTS, they're a royal pain in the ass to maintain for little to no gain.

@bkcsoft commented on GitHub (Nov 3, 2017): We do have a release train, though it was slightly delayed for v1.2... a new Minor every 2 months, RC1 created 1 month into the release. No backports to lesser Minors, but backports (or "pick-into-stable") from `master`=>`release/v1.X`. And no LTS, they're a royal pain in the ass to maintain for little to no gain.
Author
Owner

@hubyhuby commented on GitHub (Nov 4, 2017):

Ho @bkcsoft , thanks for your answer.
Then, the only thing we are missing is a page on the website explaining the roadmap / release train. At least theoretically if we are not on a precise schedule ;) Your explanation is nice and having it available to the end user is usefull. (actually I had guessed there was some kind of 2 monthe cycle. But it could be by chance)
(On a dev perspective it might be interesting to have this information displayed as-well)

@hubyhuby commented on GitHub (Nov 4, 2017): Ho @bkcsoft , thanks for your answer. Then, the only thing we are missing is a page on the website explaining the roadmap / release train. At least theoretically if we are not on a precise schedule ;) Your explanation is nice and having it available to the end user is usefull. (actually I had guessed there was some kind of 2 monthe cycle. But it could be by chance) (On a dev perspective it might be interesting to have this information displayed as-well)
Author
Owner

@bkcsoft commented on GitHub (Nov 4, 2017):

@hubyhuby You mean this explanation? 🙂 https://github.com/go-gitea/gitea/blob/master/CONTRIBUTING.md#release-cycle

As for roadmap, since we do this in our spare-time pro-bono we can't really set a roadmap as we can't really dictate what people should work on 😉

@bkcsoft commented on GitHub (Nov 4, 2017): @hubyhuby You mean this explanation? 🙂 https://github.com/go-gitea/gitea/blob/master/CONTRIBUTING.md#release-cycle As for roadmap, since we do this in our spare-time pro-bono we can't really set a roadmap as we can't really dictate what people should work on 😉
Author
Owner

@hubyhuby commented on GitHub (Nov 4, 2017):

Dear @bkcsoft ,Exactly what I was looking for !
I am custom to use other software which includes roadmaps, but now I understand that gitea prefer to use the notion of "Release cycle" which is fine with me :)

Thanks for this wonderfull software!
PS: anyhow google will scan through this and now gitea + roadmap as an answer to it :)
Bottom line if you think LTS doesn t fite in the gitea phylosophy , please close this bug to clear the deck

@hubyhuby commented on GitHub (Nov 4, 2017): Dear @bkcsoft ,Exactly what I was looking for ! I am custom to use other software which includes roadmaps, but now I understand that gitea prefer to use the notion of "Release cycle" which is fine with me :) Thanks for this wonderfull software! PS: anyhow google will scan through this and now gitea + roadmap as an answer to it :) Bottom line if you think LTS doesn t fite in the gitea phylosophy , please close this bug to clear the deck
Author
Owner

@lafriks commented on GitHub (Nov 4, 2017):

Currently I think we will close this issue

@lafriks commented on GitHub (Nov 4, 2017): Currently I think we will close this issue
Author
Owner

@tboerger commented on GitHub (Nov 5, 2017):

Gitea is a pure community project without any company backing the work, so I don't think that we are in a position to provide LTS releases.

@tboerger commented on GitHub (Nov 5, 2017): Gitea is a pure community project without any company backing the work, so I don't think that we are in a position to provide LTS releases.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#1167