Consider a simpler branching strategy

[davestephens]

I've been thinking this for a while, but wanted to open this issue to get some thoughts down and generate some discussion :-)

Tl;DR; I think that the master/0.0.10-alpha/0.0.11-alpha strategy is unnecessarily complicated for ENiGMA-BBS and everything should be based around master.

• I'm wondering if there are enough (any?) breaking changes pushed that justify breaking out new features into long-running (months long!) branches.
• master is "master", develop new features on feature branches, then merge once complete. The existing install script allows people to pick what branch to install from if they want to test a new feature (e.g. a Node upgrade).
• Would prevent new users wondering where to start.
• Branches are named by what they actually contain rather than a nondescript "alpha".
• Would make the Docker build process simpler (no need to update to 0.0.X-alpha)
• Removes need to backport fixes.
• Docs will always be up to date at https://nuskooler.github.io/enigma-bbs/
• Makes development easier. Right now, changes are merged to the latest alpha branch, then backported further if they're a fix. Also - where should a PR be raised against? master, alpha-X or ???
• Updating from 0.X-alpha to 0.Y-alpha is no longer a thing, it's just "rerun the installer from master", or docker pull and boom, you're up to date.
• New breaking changes that need to be merged can be feature-flagged and enabled when a user decides.

Overall, I think it'd be less admin (yahoo!) and a simpler release, build and update experience 👍

Would appreciate thoughts!

[NuSkooler]

At the very basic level, I agree with pretty much all of the above and have considered this a few times. The versioned branches have been in place as at least up until the 0.0.10-beta branch, things have been semi unstable. Since there are no binary/packaged releases, this can be problematic.

Regarding Docker, I think it may easier to get the Dockerfile and related assets into the main repo here as well.

I think if we did the above, the install script doesn't need to worry about anything but "latest" (that is, master). We need to be more careful about any breaking features and migrations though. There has been a version or two that required some manual DB work, and some of the item format (of which there is actually a few more to do) stuff meant existing menus/themes people developed required some attention.

The version could perhaps bump up to SemVer and use a short Git hash for the -extra bit.

[tracker1]

Similarly, could generate and tag a dockerhub image as part of github's actions ci/cd pipeline if you bring the Dockerfile in. Probably easier for most people to use a docker image at this point, just pointing to volume mount(s) for config, data and local mods?

The docker image could have DOSemu as well if possible as an extended feature with a volume for dos doors.

[NuSkooler]

Docker layers allow for base / base + dosemu / so on.

[davestephens]

We need to be more careful about any breaking features and migrations though. There has been a version or two that required some manual DB work

What about adopting a Rails-style migration strategy? https://github.com/db-migrate/node-db-migrate would do exactly what we need...

Re menu changes, yeah, that's harder - but a fact of life living off master ;-)

[NuSkooler]

What about adopting a Rails-style migration strategy? https://github.com/db-migrate/node-db-migrate would do exactly what we need...

Looks like Alembic migrations. At this point, more trouble than it's worth IMO. There have only been a couple of such changes I can think of which could just be coded in the database.js if needed.

[NuSkooler]

I'm sure everyone is familiar, but for anyone reading that is not: https://semver.org/

[NuSkooler]

@davestephens Thoughts on the Docker issues above?

[davestephens]

Semver or GitVersion is cool with me - as long as it shows where (commit and branch) the image comes from then we're good.

As @tracker1 says we can get the dockerhub build pipeline hooked to this repo (rather than off my docker repo as it is now).

I don't really see any issues per-se, just stuff that needs to be done. I'd like to be able to help out with merging the Docker stuff from my repo onto master.

Dunno if you remember but we created this a couple of years back, so we'd just need to get the various bits and bobs set up to start using it. If you want to give me some sort of access to this repo so I can do the GitHub pipelines stuff, I'd be happy to handle that too...

[NuSkooler]

@davestephens Access invite sent. I could have sworn I did this a while back, guess not 😩

I'll start going through notes and what to prep for switching this over (maybe there isn't much to do). Any notes about version/etc. I'll add here.

[NuSkooler]

master is now mainline. Please give it a test. Closing this one so specific issues can be created from this point on.