Creating release branches

[DeveloperDurp]

I remember watching a video and I think you were talking about your old tool were some features would creep in and some things didn't work right. A suggestion that might help that is to create a release branch and have your URL point to the latest release. Example would be creating a branch called Release/1.0 then after some updates you could create a Release/1.1

I am not familiar with how GitHub actions work but in Gitlab for example you could have a pipeline job run and modify a variable in your repo and commit it. So that way you could have say a $Version variable that could be updated by the release version and update and URLs inside the script itself.

also allows you to reference previous versions much easier too

[Carterpersall]

I think the intent of having separate Test and Main branches is to prevent exactly this. It might still be a good idea though to separate versions into releases and provide a changelog for each.

[DeveloperDurp]

Yeah, it's good to have the test and main branches at a minimum, though it's up to Chris since it's additional work. I have had so many discussions about the different types of gitflows that it's one of those things I think about now lol.

[Firecul]

I think I'd much rather have a version release pattern. I know it doesn't matter a lot but at the end of the day, running bleeding edge code could always end badly. If you can say specify v1.3 for example you know flags/arguements will be compatible. It also gives you a chance to run "known" code rather than pulling the latest every time.

[fauxcuss]

I keep seeing people reporting the same problems over and over, and some people saying, "I'm still getting this problem." The main branch, which I suspect is what most people are downloading, hasn't been updated since Jul 29.

If fixes were merged back into the main branch more regularly, there would be fewer duplicate bug reports and less frustration for existing and new users.

I'm kind of new to Git and GitHub, so feel free to help my understanding. I was getting the impression that it was common to create branches to fix bugs, then merge them into the main branch or a test branch. But isn't putting everything into a test branch likely to just hold up a merge into the main branch and delay the release of many needed fixes on the released version of the script?

I'm here to learn. Not to criticize, just to be clear.

[DeveloperDurp]

Not much has changed with the main script since then and I think in part having everyone working of the test branch is so Chris can keep his "golden copy" and ensure no one did anything funny. Chris only has so many hours in a day so if we had a bunch of changes he would have to review them individually.

One of the things I have been working on with the test script outside of the runspaces is allowing the script to be a little more dynamic so it's easier to update the code. Sadly I keep running into random bugs with the runspaces and then getting sidetracted with work so I haven't been able to finish it.

[ChrisTitusTech]

I really think this is the way to go. On major updates I'll create an archive branch for the old version.

[Firecul]

Tags would also work and might be simpler to manage?
Although, branches might be easier for non-git people

[ChrisTitusTech]

Yeah I'll try to work with both more. I completely forgot about tags

[DeveloperDurp]

There are multiple ways to skin a cat, I think this is where "devops" would come into play. Something like a github action to replace a variable inside the powershell script to tell it which branch to point to on execution.

Could probably use github pages and the latest release branch gets deployed as a page and all URLs point to that instead. That way if you want to roll back you run the action for a previous release branch and that gets deployed.