As a community member and minor contributor this sounds good. I had a few questions.
- Is there only ever a single patch version supported at a time? - Will there be a regular cadence of merging "main" into "next" so actively developed work is up-to-date? Would this be done by core team members or would community members be involved? - With "next" being a single branch would it be all-or-nothing to merge into "main", or would changes be cherry-picked for the next up-coming version? > 2.0.0: > * Backward-compatible, binary variation of Guacamole protocol (assuming > browsers are now capable of handling this efficiently, I have a rough sketch > of how this might look and how it might improve on the processing required) Is there a JIRA issue for this? I have some thoughts and experimentation around switching to binary web socket frames, assuming that is what this refers to. - Christopher Speck > On Feb 22, 2024, at 3:44 AM, Michael Jumper <mjum...@apache.org> wrote: > > (This is particularly relevant to the Angular and X.Org changes.) > > We have a ton of changes in flight of all sizes, both from Guacamole > committers and from contributors. The larger changes tend to get stuck > because ... they're large. The smaller changes tend to get stuck because of > basic issues with style which, while important, also serve as a roadblock > that makes things difficult for contributors and reviewers alike (there's > lots of back-and-forth, and lack of time leads to PRs eventually getting > ignored/forgotten). > > I think we should adopt some changes to our branching and code review methods > to allow things to move forward more efficiently and without risking breaking > mainline. > > To be clear, I'm not proposing that we alter the scope of review. Instead, I > think we should make it significantly easier for contributors to abide by the > style guidelines by providing some sort of script within the guacamole-client > and guacamole-server source that allows contributors to automatically > check/correct their own changes. Review on our side can then be streamlined > to just: > > 1) Verifying that script reports everything is clean. > 2) Verifying the pure technical merit of the proposed changes. > > With respect to avoiding changes getting stuck due to sheer size, I propose > we adopt a different branching strategy that builds off the patch release > procedures we recently adopted. Instead of a single "master" branch, I > suggest a set of 3 primary development branches: > > (1) "patch" - Receives any changes that are bugfixes or minor improvements > that do not affect documentation. This is essentially equivalent to what > we've been doing with the staging branches for patch releases, except that > there would no longer be any need to create those staging branches until the > release process is actually underway. The base branch for any changes that > qualify would always consistently and simply be "patch". > > (2) "main" - Replaces current "master", receives all changes that are not > huge changes that would warrant a full major version bump. Changes merged to > "patch" get manually merged back to "main". > > (3) "next" - Receives any changes that are so huge that they would warrant a > full major version bump. Changes merged to "main" get manually merged to > "next". In some cases, changes made against "main" may need to be > reimplemented against "next". > > Now on to the... > > ----- PROPOSED ROADMAP ----- > > 1.5.5: > > * Remaining items already listed in JIRA > * Any bugfixes that have already been merged to master but are missing from > previous patch releases > > 1.5.6+: > > * Any issues identified in 1.5.5 > * Any changes related to automated style checks > * Duo v4 (if possible) > * Basic improvements/fixes for known issues with the terminal emulator > > 1.6.0: > > * Remaining items already listed in JIRA > * The (experimental) X.org driver > * Finalize the migration to guacamole-common-js' improved event system > * Add remaining events for guacamole-ext's improved event system > * Generalize the Docker image to no longer require manually mapping variables > to properties (to avoid any future issues with unmapped or incorrectly mapped > properties) > * Support FreeRDP 3.0 > * Improvements to the speed and efficiency guac_common_surface (and moving > the surface to libguac) <- I have an automatic scroll detection algorithm > that seems to work pretty well > > 1.7.0+: > > * Support for WebAuthn > * Ability to automatically apply/update the database schema. > > 2.0.0: > > * The AngularJS -> Angular migration. > * Migrate from javax.* to jakarta.*, thus supporting Tomcat 10 while dropping > support for Tomcat 9 and older. > * Backward-compatible, binary variation of Guacamole protocol (assuming > browsers are now capable of handling this efficiently, I have a rough sketch > of how this might look and how it might improve on the processing required) > > 2.1.0+: > > * Improve admin UX regarding management of objects (relegate some parameters > to an "advanced" tab/view, add tooltips and links to help). > * Load balancing / HA support for the webapp itself > > Thoughts? > > - Mike
