We need to stop pulling into the Master branch.

[d8ahazard]

This is a pretty straightforward observation, but one I think that really needs to be taken into account here.

This project is now HUGE. My email is just flooded because people are constantly opening issues and PR's, which is great.

But what is not great is when a fully breaking change gets implemented because, right now, the process is just "Chuck it into Main!".

I get it, and I do that with my own smaller projects. But given the sheer complexity of this app, I think it's definitely worth discussing creating a Dev branch, and working there as we have been from Master.

For new features, we create a new branch, and when a PR is submitted, have some kind of "Yes, this was tested with all the things" check before anything gets merged to dev.

Once it's in Dev, then we let the more adventurous members of the community test and submit bug reports, which we then fix, and only then - once we're sure nothing is broken at least the basics are working - do we push it up to Main.

Sure, there will still probably be bugs and stuff here and there, but at the very least, we'll have a separate "stable" version of the app to use when we just need to use it, and a more bleeding-edge version to test and expect bugs.

Just my 2c. Not my project, but I think it would help a LOT.

[trufty]

Personally I'd just rather see Tags used. Less branch madness, and you can just make a new tag when you feel master is stable.

[Luke2642]

I disagree. I can't be the only one who is loving doing a git clone every couple of days and seeing what exciting new features have appeared, however raw!

If automatic's vision is to become a "dependable professional tool" and transition to being an ecosystem platform, as a server with api, and gradio is the flagship front end, then as @trufty said, tags are a good first step.

But now, no. The project is special because it's the bleeding edge of features, discussion, fun, excitement and contributors. Protect, nurture and encourage that enthusiasm as much as possible!

[MasterZap]

a) You should be doing git pull, not a new clone :)
b) You could just as easily be pulling from the dev branch. All the fun would be there. master would just be a "less breaks" branch.

[Luke2642]

a) I do a new clone, in case it breaks :)
b) If your company PR department had decided it's "on brand" for a reliable product, you'd be 100% right. But it's not! It's irrelevant! The most important thing here is Automatic writing (and pulling in) seriously impressive features and ports of code from academic papers published only days or weeks ago! It's incredibly special, this momentum!

If the odd js button breaks, so what!!! It'll be fixed in hours. The most important thing is that automatic and the community keep being awesome, keep making master even more awesome, keep everyone on master! That's their gift to the world, not "PR department authorised user A/B tested reliable app updates on a 4 week cadence". Give me a break!!!

[gvastethecreator]

if you don't want to take a risk pulling from master just don't do it.

[horribleCodes]

I don't mind the experimental main branch, but you could have a "safe" branch, where you only merge up to a point you know it safe. Hell, you could make your own fork for just that.
That way, you can pull all you want without having to worry about something breaking.

[Luke2642]

Love it! 🤣 Discussion can be closed! Github has already implemented the fork feature, knock yourself out! 🤣

[d8ahazard]

I find it incredibly odd how averse some of you are to the concept of "Use a dev branch" or "Separate 'WIP' from 'known/good' code.".

Doesn't have anything to do with a PR department, or suppressing the bleeding-edge nature of this project, or anything like that.

We have a master branch where the code has been vetted and all of "the things" should just work. We have a separate "bleeding-edge"/dev branch where there is a possibility of things being broken. Fix the things, validate, merge to master. Or use tags. I'd still be pulling from the /dev branch. The suggestion was for the sake of having something in place that people could use to ensure some level of stability.

[Luke2642]

Sorry, I got a bit poetic, romantic... it's about the people, as much as the code.

Are you volunteering to fork an official somewhat stale stable branch? Would that be an acceptable solution to you? :-)

[horribleCodes]

As someone who has yet to contribute to the repo, I want the actual collaborators decide on what would be good for development.
You're correct, it's just as easy for people to switch to an "alpha" branch or what have you, and newcomers won't have to deal with hotfixes and working out whether an error is on their or the last commit's part. It'll add overhead, sure, but as the userbase grows, making a stable version the most accessible will keep the bug reports in check, too.