<r​ajafan:xmr.se> matrix.monero.social/_matrix/media/…oad/xmr.se/BlpDdmLevimOMxlpkyBCToja

<r​ajafan:xmr.se> matrix.monero.social/_matrix/media/…oad/xmr.se/sZLmxbosXlfCfHvpTzttvdIa

<r​ajafan:xmr.se> Which option is better?

<r​ajafan:xmr.se> first or second

<r​ajafan:xmr.se> thanks in advance for your help

Definitely the second

.merge+ 9904 9895 9893 9892 9889 9888 9887 9886 9884 9881 9879 9876 9875 9873 9872 9863 9857 9851 9848

Added

.merge+ 9795

...

<b​inarybaron:matrix.org> Can someone confirm what the "outputs" argument does for sweep_all? Is "outputs" the number of outputs I will be creating? How will they be constructed? All of equal size?

yes

that's not a -dev question. use #monero in the future.

.merges

.merges

.merge+ 9859

Added

<s​yntheticbird:monero.social> 22 august 2024:

<s​yntheticbird:monero.social> hackerone.com/reports/2677306

<s​yntheticbird:monero.social> 1 september 2024:

<s​yntheticbird:monero.social> hackerone.com/reports/2693786

<s​yntheticbird:monero.social> 21 november 2024:

<s​yntheticbird:monero.social> hackerone.com/reports/2858802

<s​yntheticbird:monero.social> 23 december 2024:

<s​yntheticbird:monero.social> hackerone.com/reports/2912194

<s​yntheticbird:monero.social> The four vulnerabilities (which none are not at least high severity) has been resolved April 8th 2025. Most important delay has been 7 months and a half between report and release.

<s​yntheticbird:monero.social> Surely this can be improved? Discussed? Here or during Monero Tech Meeting?

we don't use the severity setting inside hackerone, it's up to what the reporter sets

what would help is more devs, both in quicker and more thorough reviews and tracking down bugs during the testing phase

we could also increase the frequency of releases but each release requires the coordination of a lot of people so if an exploit is currently not critical and exploited it sometimes make sense to bundle together multiple vulnerability fixes, it's always a tradeoff

this release was especially bad in delays due to a large amount of code changes being merged which required more testing than usual, the lack of a follow up release for now is a good sign that we didn't miss anything obvious

<s​yntheticbird:monero.social> re: reviews, Some of the less complex PRs can pass with just 2 additional reviews. 3 reviews is just asking for delay whenever there is a minor commit change.

<s​yntheticbird:monero.social> re: releases, i agree this should be increased, not just for meeting the 90 days disclosure rule but also heat up the engine because from what I have witnessed even during a large scale RPC DoS campaign we weren't able to either make a release, or communicate to operators through official channels. I do understand the the TODO list is kinda huge, but there was also a lot of people<clipped message>

<s​yntheticbird:monero.social> on the teeth for testing and completing syncs, reporting issues, fixing them. I don't think 3 months release cycle is unrealistic and would definitely help out at the current "mergeathon" issue. 4 months as a HARD CAP. I'm part of the one who thinks release should be tagged from master. The [Release] PRs are slowing down in 99% of the cases.

<s​yntheticbird:monero.social> re: tradeoff, honestly this was bad, i understand it, but from experience, and im sure you'll agree, monero is always late on PRs, waiting for a single review on a vuln PR for the incoming release turns into waiting week if not a month (as happened in april). sagewilder was wondering if its fix would be included in january and it was told probably not. Release ended up in April. a<clipped message>

<s​yntheticbird:monero.social> nyway, If the risk is to have to make a new urgent release just some weeks after, i think its worth taking it.

<s​yntheticbird:monero.social> also if it happens it would actually be faster to roll out, as the release would have already been validated for being reliable, no need for 1+ month of fixing issue

<o​frnxmr:xmr.mx> There were prs that could have broken chain syncing in this release

<o​frnxmr:xmr.mx> and the few people that were testing the releace candidates were suffering from anomalies ranging from incredible connection counts, to write locking issues, and even broken syncing

<o​frnxmr:xmr.mx> the point of release branch is to push bugfixes while avoiding feature additions. This line has blurred, imo, due to the lack of released off of master. As a result we push needed features - like background sync or reducing disk writes (that can cause breakage) to release branch

<b​oog900:monero.social> > reducing disk writes

<b​oog900:monero.social> that was a vuln fix :)

<o​frnxmr:xmr.mx> If release branch was _only_ bug fixes, like an LTS, then we probably could have pushed out a release faster. W/o frequent hard forks, i think we should be tagging master every 6 months _in addition_ to an LTS release

<o​frnxmr:xmr.mx> That pr was open for a very long time and was one of the last to be merged - and broke syncing

<b​oog900:monero.social> was a big fix

<s​yntheticbird:monero.social> Tbc: Every 6 months 1 monerod-features + monerod-lts OR Every 6 months monerod is based on master and in between a release from LTS branch?

<b​oog900:monero.social> hackerone.com/reports/2315026

<o​frnxmr:xmr.mx> either or. Specifically releasing master every 6 months. Release/lts branch could/should be possible at the same time (or potentially more often), since its just bugfixes

<s​yntheticbird:monero.social> 💀

<o​frnxmr:xmr.mx> Why does it feel like 9135 was opened before january

<s​yntheticbird:monero.social> its called recycling my dear

<o​frnxmr:xmr.mx> monero-project/monero #9135

<o​frnxmr:xmr.mx> i knew i wasnt crazy

<s​yntheticbird:monero.social> > on Jan 24, 2024

<s​yntheticbird:monero.social> you are crazy

<o​frnxmr:xmr.mx> oh, years

<o​frnxmr:xmr.mx> No, not crazy, just cant read

<o​frnxmr:xmr.mx> we released 18.3.4 while that pr was open

fix was not ready yet for v0.18.3.4

<0​xfffc:monero.social> I totally agree. Our current releasing is slow

<o​frnxmr:xmr.mx> Also wasnt ready for 18.4.0 :P

<s​yntheticbird:monero.social> I think everyone agree releasing should be faster

<s​yntheticbird:monero.social> what happened for 18.4.0 is that every vuln reported pushed the date little by little until April

<s​yntheticbird:monero.social> Feburary* by which testing for release began we bugs were discovered

<o​frnxmr:xmr.mx> Tag master every 6 months 👨‍⚖️

<o​frnxmr:xmr.mx> And replace release branch every 12-24(?) or hard fork, whichever comes sooner 👨‍⚖️

<s​yntheticbird:monero.social> selsta would this discussion be better put on Github? This could invite more participants to the discussion.

<o​frnxmr:xmr.mx> most invested parties are here

<s​yntheticbird:monero.social> most are either sleeping or busy, async discussion is better

<o​frnxmr:xmr.mx> the main thing is to iron out the details, i think. (mostly frequency)

<s​yntheticbird:monero.social> Honestly I think monerod is lacking the dev force necessary for putting up a master + LTS branch. This is adding mental burden for PR OP and slow out the reviews a lot. But ultimately this about to maintainers to decide and main devs/contributors to say if they are more comfortable working/endorsing a single branch or two.

<o​frnxmr:xmr.mx> We currently waste dev force by keeping release on life support

<o​frnxmr:xmr.mx> in this case, Master tags would hold all new features, and release would be _ONLY_ bug fixes

<o​frnxmr:xmr.mx> Instead of current, where releasing/tagging master has no timeline, so we keep adding features to release. Forcing people to write prs to account for the differences between branches (like c++14vs17)

<s​yntheticbird:monero.social> Having different C++ versions between branch is crazy

one branch does not make sense, it would significantly increase testing necessary before each release compared to a release branch which ideally only gets bug fixes

<a​remor:matrix.org> Re: “more devs” - Bitcoin has a PR club that helps on-board new devs. Perhaps some program can be devised to on-board people to the code base.

<o​frnxmr:xmr.mx> old:

<o​frnxmr:xmr.mx> master -> only tags/releases/branches every 2+ years because we dont hard fork

<o​frnxmr:xmr.mx> release: backporting master features because the ecosystem needs it

<o​frnxmr:xmr.mx> proposed:

<o​frnxmr:xmr.mx> master: tags every 6 months & branches every 12 or 24

<o​frnxmr:xmr.mx> Release: bug fixes only, branched from master every 12 or 24 months

it would also make it more difficult to introduce things like guix because it means once it's merged it would be necessary to use in the next release, even if it's not fully ready yet

<s​yntheticbird:monero.social> selsta: understandable

<s​yntheticbird:monero.social> ofrnxmr: i support this layout

i'm against tags on master branch

<a​remor:matrix.org> Something that’s not ready to release does not go into master. It goes into a feature branch. Maybe a shared development branch.

<o​frnxmr:xmr.mx> Well the master tags would be like ubuntu's short term releases @selsta

i'm ok with more frequent branching from master to avoid large periods of time without new features, and it would allow to keep the release branch bug fix only

but even if we would do that every 6 months there would still be feature PRs that people want in release branch because it's useful for some downstream project

<0​xfffc:monero.social> I am gonna fork monero. ( not the network, software ). Maintaining a fully modernized monerod implementation.

<0​xfffc:monero.social> Much easier and faster to try and broke.

<0​xfffc:monero.social> Possibly to move c++20. Removing old support much faster.

<o​frnxmr:xmr.mx> Imo the problem with _branching_ from master too frequently, means that we are effectively dropping lts type releases

<0​xfffc:monero.social> Canary release basically.

<0​xfffc:monero.social> Removing some old date libraries we have. Slow codes that we don’t touch.

<s​yntheticbird:monero.social> selsta: we can first try to be more conservative on feature addition to release. Formalizing release branch as being bug fixes only + important features, and putting appropriate tags on PRs would be a beginning.

<o​frnxmr:xmr.mx> But tagging from master allows us to keep the "lts" type, as well as having new features available. Allows for less frequent branching, while still putting out modern releases

<a​remor:matrix.org> To keep features released quickly means that the automated test suite needs to be beefed up. That’s the easiest, safest way to release master frequently

<a​remor:matrix.org> A release branch is similar to a tag. It just lets every one know what was released at what time and if an urgent bug is found, **only** then is release branch developed upon. Is there for quick bug fixes. Not for active development.

<o​frnxmr:xmr.mx> This is how it currently is, but we make a lot of exceptions because it takes so long to tag master.

<s​yntheticbird:monero.social> alright

<o​frnxmr:xmr.mx> The cause of slipping features into release, is because master is very past due

<s​yntheticbird:monero.social> then just increase branching of master to 6 months

<a​remor:matrix.org> That needs to stop

<a​remor:matrix.org> Master needs to be fixed. Otherwise this is a perpetual cycle of fragmentation

I don't understand how tag from master should work. Let's say we tag from master and release, then there is a bug we need to fix... what now? Tag again from master and potentially have new large features in we didn't want for a pure bug fix release?

<o​frnxmr:xmr.mx> that causes the end of "lts" type releases if we branch master every 6 mth

<o​frnxmr:xmr.mx> theres nothing wrong with master, aside from that we dont release it

<a​remor:matrix.org> Lts means large releases and that has the same characteristics that we currently have. Large releases are prune to large bugs being found.

<o​frnxmr:xmr.mx> Selsta, my last msg was to aremor

<a​remor:matrix.org> Release often to reduce diff sizes

<o​frnxmr:xmr.mx> My reply to selsta is: yes

<a​remor:matrix.org> It’s not being released because it’s hard to ensure there’s no major bugs in it, and it contains unfinished hard forks

<a​remor:matrix.org> If those 2 things are fixed, it can be released

<s​yntheticbird:monero.social> in the context of vulns, I welcome any layout that lighten a specific branch to which fixes can be quickly deployed with minimal frictions due to usual PR activity

<o​frnxmr:xmr.mx> no, its not being released because we dont hard fork often anymore

<o​frnxmr:xmr.mx> We used to release master every 6months

<o​frnxmr:xmr.mx> Its not-not being released because its buggy

<o​frnxmr:xmr.mx> And if it IS buggy, its because its gone 2 years without being thoroughly tested, and should NOT be bundled up and shipped with fcmp.

<a​remor:matrix.org> Bug fixes go on top of release branches, like ofrnxmr said. And only that go on release branches.

<a​remor:matrix.org> If that’s the case the HFs shouldn’t be in master. Until absolutely desired.

<s​yntheticbird:monero.social> Unlike most hardforks FCMP++ introduce heavy changes everywhere, including in the toolchain, so it's not something i would expect to be put into a "bug fix only" branch

<o​frnxmr:xmr.mx> +100

<a​remor:matrix.org> New features are not bug fixes

<a​remor:matrix.org> If it’s too risky to go into master, but let’s say 5 people need to work on it at the same time, that’s called a development branch

<o​frnxmr:xmr.mx> they have those on their own repos

<s​yntheticbird:monero.social> Yes

<o​frnxmr:xmr.mx> Master isnt a development branch, its supposed to be stable at all times

<s​yntheticbird:monero.social> I like the master | dev/next layout

<s​yntheticbird:monero.social> tho it just shift the name from master | release

<a​remor:matrix.org> The team is currently treating release as if it’s named master and treating master as if it’s a development branch.

<o​frnxmr:xmr.mx> no, youre wrong

<a​remor:matrix.org> Once I realized that I was more ok with it but this “dev branch” is sticking around too long and it’s not getting released

<o​frnxmr:xmr.mx> Master is not a dev branch, and its not being used as one

<o​frnxmr:xmr.mx> Dev branches for fcmp are on jberman and jeffros repos

<a​remor:matrix.org> Which is an issue. Dev should still merge into master (get released) often so that the fragmentation doesn’t get too large

<a​remor:matrix.org> Those are feature branches

<a​remor:matrix.org> Feature branches are shared less than dev branches. There’s usually only 1 dev branch per repo

<a​remor:matrix.org> Aka how master is currently being treated

<s​yntheticbird:monero.social> I get aremor point

<o​frnxmr:xmr.mx> Release branches are intentionally fragmented

<s​yntheticbird:monero.social> Release branches shouldn't be more than a buffer imo

<o​frnxmr:xmr.mx> They dont share a common history with master beyond the last hard fork

<a​remor:matrix.org> It’s all detailed here: atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

<o​frnxmr:xmr.mx> release branches are, at least in part, due to our "promises" of support for X amount of time

<o​frnxmr:xmr.mx> support of X platform or library*

<s​yntheticbird:monero.social> selsta: According to what I've understood this would be tagged from release

<s​yntheticbird:monero.social> We are just saying "include new features every 6 months by branching master", otherwise just release bug fixes

but for that to happen you need to branch, otherwise release would be behind master

<o​frnxmr:xmr.mx> They are supposed to be feature and (major version) dependency freezes

<s​yntheticbird:monero.social> selsta you meant ahead?

no, behind. if you tag from master then you can't just apply a bug fix to release without a) branching or b) merging master to an existing release branch

<o​frnxmr:xmr.mx> syn, Thats not what i'm saying. I'm saying keep a feature freeze branch with bug fixes only. Branch master to create a new one every 12-24 months. as well as tag master and put out releases off of master every 6mth

<a​remor:matrix.org> Selsta, after you tag from master, that is the new release branch. Bug fixes are then applied to that new release branch. Not the old one.

<o​frnxmr:xmr.mx> we would have 2 releases out. One based on v0.19 branch, and one based on master tag

tagging master branch does not create a branch

<o​frnxmr:xmr.mx> I wouldnt replace the release branch with a master tag every 6 months. Thats too many changes for a long term support

<s​yntheticbird:monero.social> selsta, first branch master to a new release branch, then tag this new release branch

<a​remor:matrix.org> Semantic versioning: when a minor release is made, it is a release branch. Bug fixes that occur to it, are committed in top, back ported to master, and released as “patch” versions (Semantic Versioning).

<o​frnxmr:xmr.mx> I'd only branch from master every 12 or 24 months (or @ hard fork)

<o​frnxmr:xmr.mx> selsta, first branch master to a new release branch (release-v0.19), then tag this new release branch (v0.19.0.0). this will be bugfix-only branch for 12-24mths. Every 6 months, tag master as v0.20.0.0-selsta. After 12-24 months (or fcmp hf), branch is as release-v0.20 (replaces 19 branch)

<a​remor:matrix.org> I agree with everything except the timing. The timing need not be concrete. It should really be as often as possible, to decrease fragmentation. A super thorough test suite allows this.

<o​frnxmr:xmr.mx> which timeline? The 12-24mth branching? Or the 6mth tags?

<a​remor:matrix.org> “<s​elsta> tagging master branch does not create a branch” — you do both at the same time. Make the release branch and tag it.

<a​remor:matrix.org> Both. The timing doesn’t need to be written in stone

<a​remor:matrix.org> As long as there’s no HF you can keep releasing

<a​remor:matrix.org> And it should be frequent.

<o​frnxmr:xmr.mx> for release, i ddint say "dont release for 12-24", you can release every month if you want to. I said, dont replace the long term support branch more often than that (unless a HF)

<s​yntheticbird:monero.social> where would feature additions fits in ?

<a​remor:matrix.org> Big releases means big bugs. Or big testing efforts because there more to cover.

<o​frnxmr:xmr.mx> master tags every 6 months would bring new features, and every 12 months would branch

<a​remor:matrix.org> Essentially it’s tech debt that one needs to clean up by releasing. By releasing often, you keep the tech debit smaller.

<o​frnxmr:xmr.mx> Regular users like myself would likely run masters tags, while exchanges and pools would stick to release branches

<s​yntheticbird:monero.social> I think selsta is against two types of releases

<a​remor:matrix.org> Merged into dev branch

<s​yntheticbird:monero.social> yeah i got that

<a​remor:matrix.org> So the normal flow is, feature branch —> dev branch —> master —> release and tag

<a​remor:matrix.org> Patch releases aka hot fixes build off of release branches and are back ported to master. That’s essentially it

<o​frnxmr:xmr.mx> I think branching off of master too often is a bad idea and requires a third (dev) branch, which further complicates the pr workflow

<s​yntheticbird:monero.social> i agree with ofrn

<a​remor:matrix.org> So am I

<s​yntheticbird:monero.social> Maybe we're trying to solve the problem from the wrong end. What are sure we want for users at end? bug fixes at most every 3 months, feature addition targeted every 6 months ?

<s​yntheticbird:monero.social> Maybe we're trying to solve the problem from the wrong end. What are sure we want for users at end? bug fixes at most every 3 months, feature addition targeted every 6 months?

<o​frnxmr:xmr.mx> i'm pro 2 types of releases. "release" branch should be simple, no surprised, all bug fixes, not really in need of testing. Very low effort to maintain.

<o​frnxmr:xmr.mx> master tags are the bread and butter.

<a​remor:matrix.org> The dev branch need not be working 100% all the time. Reviews can be lighting. Master should be in a working state 24/7

<a​remor:matrix.org> Dev is basically the developer’s version of Continuous Integration. It’s so that devs are not clobbering each other constantly.

<a​remor:matrix.org> Right now jberman and jeffro probably have to pull from each others’ private repos. If there was a dev branch, they should merge into that, and pull from it into their feature branches often, to always know the progress of the other.

<o​frnxmr:xmr.mx> as intended

<o​frnxmr:xmr.mx> Tob as luigi arent babysitting a dev branch

<o​frnxmr:xmr.mx> Every pr merged to any branch must be approved. the main repo is not a playground or a workshop

<a​remor:matrix.org> Faster, smaller releases for faster bug fixes and less effort needed for testing a release

<a​remor:matrix.org> That’s my point. They shouldn’t

<s​yntheticbird:monero.social> I agree with you on less fragmentation but even if tomorrow selsta wanted to tag, it's not guaranteed luigi will be there to sign it in the coming weeks

<a​remor:matrix.org> The higher up devs should basically have write access to it

<a​remor:matrix.org> Reviews for it are light

<o​frnxmr:xmr.mx> lmfao

<a​remor:matrix.org> If at all

<o​frnxmr:xmr.mx> NACK'ing anybody commiting directly to the repo, period

<o​frnxmr:xmr.mx> I dont care if the branch is called dangerous-unverified-do-not-use

not seeing a suggestion that i like so far

<a​remor:matrix.org> Then it just remains untagged until they tag it. That problem would have to be addressed separately. But at least selsta and devs are no longer the cause.

<s​yntheticbird:monero.social> selsta thats fine, im a little lost too. Probably worth putting each proposal into paper from which they can be refined and issues tackled

<a​remor:matrix.org> Git flow is an industry standard.

<a​remor:matrix.org> There’s 2 others I know of. “Trunk”, branching. It’s essentially the exact opposite. Really for small, trusted teams. Every dev is responsible for not breaking master essential. 1 main branch, nothing else. Maybe 0 to 2 reviews required for committing to it.

<a​remor:matrix.org> The 3rd is what GitHub does by default, the pull request model, with 1 main branch and all devs doing whatever they want on their separate repositories

<a​remor:matrix.org> Git Flow has been documented for 10+ years now

<a​remor:matrix.org> atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

<s​yntheticbird:monero.social> Let's summarize:

<s​yntheticbird:monero.social> We want faster releases, which comes with less PRs frictions and easier testing. Also a formalized way of pushing fixes.

<s​yntheticbird:monero.social> Current way: The `master` branch is holding every advancements and is "the most ahead", welcoming PRs needed for preparing the next hard fork. By this logic, A `v0.*.0` **release** branch is created at every hard fork, meant to be stable, it should only welcome bug fixes commits or feature really wished by the community. It also permit to freeze dependencies versions like boost, etc...

<s​yntheticbird:monero.social> Cons: There is no clear policy on when a feature should be backported to release, We have (lost) release timeline requirement formalized. Light features can take years before being shipped to release because waiting on a hard fork.

<s​yntheticbird:monero.social> Ofrnxmr proposal: Releases are tagged/created every 6 months from `master` and an additional `LTS` release from a `v0.*.0` **LTS** branch that is forcibly renewed (meaning creating a new one and dropping the old one) from master every 12 months or @ hardfork. Similar to the old release the LTS branch should only contain bug fixes and freeze dependencies requirements.

<s​yntheticbird:monero.social> Pros: Features are known to be shipped in 6 months, People have the guarantee of 12 month support library freeze.

<s​yntheticbird:monero.social> Cons: This add mental burden as the master releases and LTS releases can be asynchronous. In order to guarantee stability in `master` (which will still receive HF PRs) we cannot decrease the master release window, which could cause a delay between LTS fixes and master fixes?

<s​yntheticbird:monero.social> aremor proposal: Use the documented Git Flow, which uses a `dev` branch which welcome PRs (feature additions), a `master` branch used for tagging releases, and intermediate `release` branch at every release cycle. When we want to release new features or current dev state we create a new `release` branch from `dev`, it will take all the commits necessary for adapting `dev` state in<clipped message>

<s​yntheticbird:monero.social> to a proper release (changing monerod versions, documentation, readme, preparing signatures, etc...), when the release is ready to ship we merge `release` back into both `master` (which we then tag and release) and `dev`. Whenever we need to push bug fixes we're forking `master` into a `maintenance` branch, push the bug fix on this branch, then merge it into `dev` and `master`.

<s​yntheticbird:monero.social> Pros: Heavily documented and formalized

<s​yntheticbird:monero.social> Cons: Can rely on more than 3 PRs and trust maintainers on understanding it well. There are no LTS branch per say, it can be forked from `main` but it must imperatively be cleansed once `dev` is merged into `master` for a release cycle.

<s​yntheticbird:monero.social> ofrnxmr aremor please make clarifications

<s​yntheticbird:monero.social> have no release timeline requirement formalized*

<s​yntheticbird:monero.social> rely on more than 3 branches*

<o​frnxmr:xmr.mx> For the final sentence of my summary, we can decrease the master release window, and can release whenever we want. 6 months being the target deadline

<o​frnxmr:xmr.mx> So if master is and release are put out today, and we have some bugfixes to release 2 months later, we would tag and release master and release at the same time. Assuming the bugfixes arent important, master and release would be tagged and released every 6months

<o​frnxmr:xmr.mx> the idea is that the majority of the ecosystem would be running the master tags, with more sensitive environments using the frozen release branch

<o​frnxmr:xmr.mx> In retrospect, ecosystem like haveno & basicswap (wallet-rpc features), lws (targets master), wallets (use features like background sync), mining pools (subtract fee from output), would be using the master tags and we wouldnt have had to merge these features to release branch.

<o​frnxmr:xmr.mx> would still create a new release branch from master every 12 (or 24 or hard fork) months

<a​remor:matrix.org> Release branches are created from master. Once fully vetted, versions updated, tagged and released and back ported into master and dev.

<a​remor:matrix.org> Bug fixes are branches from the respective release branch and back ported to master and dev as well.

<a​remor:matrix.org> Current, but big diffs between dev and master should be avoided. Big diffs between master and the latest release should also be avoid. Keeping master in a releasable state at all times, ideally can release it whenever something big enough enters it.

<a​remor:matrix.org> The only real branches are master and dev. When selsta sees we have something meaningful, they create a new release from master and out it goes. Bug fixes happen as needed on the respective release branches.

<s​yntheticbird:monero.social> This is actually in opposition with the documentation you sent:

<s​yntheticbird:monero.social> > Once develop has acquired enough features for a release (or a predetermined release date is approaching), you fork a release branch off of develop

<s​yntheticbird:monero.social> And I believe the sent link to make more sense

<a​remor:matrix.org> Correct, but big diffs between dev and master should be avoided. Big diffs between master and the latest release should also be avoided. Keeping master in a releasable state at all times, ideally can release it whenever something big enough enters it.

<a​remor:matrix.org> Checking

<a​remor:matrix.org> That works as well. That’s not the way u started doing it in 2014 but it works. Than master is only commits from release branches.

<a​remor:matrix.org> That works as well. That’s not the way I started doing it in 2014 but it works. Than master is only commits from release branches.

<s​yntheticbird:monero.social> What I appreciate from the gitflow workflow is that it make a smarter usage of branching to avoid having to make a single PR for two different branches.

<a​remor:matrix.org> In that sense, then master is even less important to the average developer. They’re only concerned about merging to develop. Master is for documentation purposes.

<a​remor:matrix.org> Yeah it’s one directional excluding bug fixes.

<s​yntheticbird:monero.social> For PR adding feature request or anything this will be in `dev`, for any bugfix this will needs to create a new "maintenance" branch which will immediately be merged into dev and master. Obviously this "maintenance" can buffer to take many commits but it ideally it should be short time.

<s​yntheticbird:monero.social> Main issue I see with Git Flow is no support for dependency freeze/LTS-like branch

<s​yntheticbird:monero.social> master and dev always end up synchronized because we're merging changes in both

<s​yntheticbird:monero.social> I mean I don't think this is a bad thing

<s​yntheticbird:monero.social> since I am against two types of release

<s​yntheticbird:monero.social> anyway, selsta doesn't sound very attracted by it

<s​yntheticbird:monero.social> i think mainly because of its way more orchestrated

<a​remor:matrix.org> Yeah I see why we would want dependency freezing. Should be automated in the build anyway.

<s​yntheticbird:monero.social> and prone to conflict

<a​remor:matrix.org> LTS to monerod to me just means no HF. Those can be planned based on community sentiment, like they are now

<s​yntheticbird:monero.social> But you can't with GitFlow

<s​yntheticbird:monero.social> because Features are coming from dev

<s​yntheticbird:monero.social> It cannot be similar with Git Flow

<s​yntheticbird:monero.social> no HF = current release branch of bug fix + features. Git Flow only allow you to merge bug fixes into maintenance branch

<s​yntheticbird:monero.social> for features to end up in master it needs to end up in dev

<s​yntheticbird:monero.social> and since you will merge dev into master you put the whole branch

<a​remor:matrix.org> That’s why I believe we used to create release branches from master, not dev. I’m looking for documentation right now. That way dev can be more unstable than master. And when people want to see the release history, they look at the tags

<a​remor:matrix.org> But even then, something like a HF, you still don’t want it in dev unless it’s already decided it will be going out soon. Because it could cause what we have now, where it prevents getting dev and master in alignment.

<a​remor:matrix.org> It’d be better to keep it as a developer’s feature branch until the HF has been planned and is close.

<s​yntheticbird:monero.social> Thats why I originally said 3+ branch

<s​yntheticbird:monero.social> we will probably end up with master, maintenance, dev, hf_preparation

<a​remor:matrix.org> “Maintence” is only a bug fix as needed. Once it merges to its two destinations and gets tagged and released, it’s dead.

<a​remor:matrix.org> You can use feature toggles to merge HFs into dev and master without “releasing” them. That’s 1 way to keep the diffs small.

<s​yntheticbird:monero.social> oh don't worry i know, thats why i said 3+ and not 4

yeah for big complicated features, it not very rare for some devs to have a somewhat long living feature branch. it happens. obviously, should be avoided & minimized as much as possible.