How is your workflow?

[nightm4re94]

^{This post has been migrated automatically from the old LITIENGINE forum (2018 - 2022).
Posted: 2019-12-09 07:29:59
User: KvaGram [] (age: 1068 days 🔥; posts: 52)}
When looking at your github page, I see you only have one active branch, the master branch, yet you have two active developers, and even more less active ones. I'm just curious. How do you manage it? How often do you get conflicts?

[nightm4re94]

^{This post has been migrated automatically from the old LITIENGINE forum (2018 - 2022).
Posted: 2019-12-09 07:54:40
User: nightm4re [Admin 👑, Mod 🔧] (age: 1567 days 🔥; posts: 185)}
This is actually a question I would have expected much sooner!
So currently, the idea is to only work on the master branch for minor features and changes during alpha to save us some time. Major changes and features are implemented by creating a thematically labelled branch. Once the development on that is finished, a pull request is set up and we make sure that it doesn't break anything from the master branch, in which case we merge it.
For collaborators, access to the main branch is forbidden, they have to submit pull requests for any changes.
Once we hit Beta, we want to alter this workflow to not work on the main branch anymore. There will be a development branch which is merged into main with every stable release. Breaking changes will still be implemented in separate branches and then merged into the dev branch.

[nightm4re94]

^{This post has been migrated automatically from the old LITIENGINE forum (2018 - 2022).
Posted: 2019-12-09 08:21:06
User: KvaGram [] (age: 1068 days 🔥; posts: 52)}
I see. So that's what your two stale branches are for then? They were used for larger features?
Also, what definition do you use for Alpha, beta and release?
Different industries use different definitions, you see, and I want want to know what to expect.

[nightm4re94]

^{This post has been migrated automatically from the old LITIENGINE forum (2018 - 2022).
Posted: 2019-12-09 08:24:52
User: KvaGram [] (age: 1068 days 🔥; posts: 52)}
As for my own workflow, I am the lead, and got one guy with me.
We try to use the master branch only for repository specific commits, readme, gitignore, mergeing etc.
All other development is in branches named for the specific developer or project / experiment.
My work on adapting the project to litiengine currently being isolated to the former.

[nightm4re94]

^{This post has been migrated automatically from the old LITIENGINE forum (2018 - 2022).
Posted: 2020-01-07 10:09:50
User: nightm4re [Admin 👑, Mod 🔧] (age: 1567 days 🔥; posts: 185)}
The stale branches are not maintained by the core project team, but by collaborator ~~~~TheRamenChef.
Both have not been merged into master because one is more of a suggestion than an actual change, and the other still needs some updates and discussions.
We use to open new branches for every larger feature and delete them once they`ve been merged.
Concerning the definition of alpha, beta, and release:

• * ~~**~~Alpha**: Since there hasn't been a pre-alpha phase or anything, this phase includes everything from the very first non-open-sourced LITIengine commit to the latest publicly available versions. Expect major API changes and feature additions to happen frequently. Because of the frequent changes, documentation does not have top priority yet. Slowly introduce the framework to the world, incorporate feedback, and form the brand *"LITIengine"*.
  By now , we have been in Alpha for almost four years.
• * ~~**~~Beta**: All core features are implemented in a stable way and can be looked up in the documentation. APIs change less frequently. The focus here is on making LITIengine reliable, well-documented, and user-friendly.
  This phase is the final stress-test for LITIengine, where we want to make sure every nook and cranny sits in the right place. Users can now familiarize with what LITIengine is finally going to work like, and provide their feedback and / or bug reports for us to apply some fixes. In addition to that, we establish compulsory guidelines for contribution and compliance, migrate to a new forum and website, and no longer work on the master branch directly. Every single bit of new code has to get tested thoroughly and incorporated in the documentation. The master branch only features the latest stable snapshot of LITIengine.
  The first ~~**~~Beta** release will be v0.5.0, set to release this year (we're currently working on ~~Dr. LEPUS, which we want to release by the middle of 2020. After that, LITIengine ****~~Beta**** has our full attention.).
• * ~~**~~Release**: At the point where we are certain that every LITIengine mechanic works in the desired way, can be accessed easily, and is covered in the documentation, we will prepare for the first production-ready release.
  Users can expect a competitive, well-tested, and easy-to-learn Java 2D game library ready for use in professional environments. By the time of release, we have composed a monetization strategy for LITIengine to reward the longstanding efforts we have put into the project. Don't worry, LITIengine will stay open-source for everyone!