On Sun, Feb 25, 2024 at 12:19 PM Thomas Kruse <[email protected]> wrote:
> I think the roadmap could benefit from a timeline regarding the support > period. Like Ubuntu or Oracle does with Java. > I'm not sure what you mean by "support period," particularly for an open source project where "support" just means "ability to ask questions on the mailing list and file bugs against a release in Jira." We will answer questions on the mailing list about any version of Guacamole, and you can file a Jira bug report against any version of Guacamole. However, if a bug exists in one version and is fixed in a new one, or a feature is introduced in some version of Guacamole, we will not back-port patches and features to previous Guacamole versions - that is, there is no maintenance of past versions of Guacamole aside from releasing and upgrading to newer versions. The answer to a question or bug may be, "just upgrade to the latest version." > In that context angularjs is no more supported by upstream which is a > big problem for enterprise customers. That was one motivation of > addressing the angular 2 migration. > Perhaps it would be a good idea to start with 2.0 beta releases to get > that going, it might be quite some effort to finish so better start early. > I have a couple of opinions/issues with this: * We don't do beta *releases* of Guacamole, and I think this may be both a Guacamole thing and an ASF thing - the closest we get to those are release candidates, and those are only when we're actually close to ready to release the software. * Even if we did beta versions, I don't think we're anywhere near ready for there to be anything that could remotely be considered a beta release of Guacamole 2.0. In particular, the PR for migrating Guacamole Client from AngularJS to Angular hasn't even been merged into any branch of the git repo, so, there isn't anything to test, let alone release. * Beta *versions* of Guacamole can always be pulled from the git repo and built that way. > As many git repos change from master to main this could be a good time > to have main for 2.0 and a 1.x branch for the angular js based guacamole. > Important changes could be backported to the 1.x branch as well. > I'm firmly opposed to trying to maintain diverging 1.x and 2.x versions of Guacamole code: * In the case of AngularJS and Angular, as you already mentioned, AngularJS is (and has been for years, now) unsupported. Why would we go to the effort to provide a replacement and then continue to support that code? * The issues that Mike is trying to address within the project for timing of getting PRs merged and into the code would not be helped, at all, by such a divergence - in fact, it would probably make it worse and/or re-introduce the problems after trying to solve them. We don't really have the level of developer support, as a community, to maintain diverging code branches. * This also has the potential to create issues with links between and compatibility of the guacamole-client and guacamole-server (guacd) code - would it follow the 1.x or 2.x version scheme? Would 1.x clients be compatible with 2.x guacd, and vice-versa. It just adds a lot of complexity that I'm not sure would add value to the project, or that the project can sustain. > Regarding future development a similar approach as with the angular > migration could be discussed for a move towards Spring Boot: having a > backend library and a spring boot wrapper project that produces > artifacts that can be run directly or deployed to tomcat if desired. I'm open to providing methods for Guacamole to easily integrate into Spring Boot - maybe we could consider a repository or method that supports it, or release Spring Boot images, similar to how we do the Docker images? That said, I would not be in favor of changes that would make Spring Boot the default or exclusive way to deliver or run Guacamole Client - anything that would be difficult to decouple from or run outside of/without Spring Boot in a stand-alone Tomcat environment. I fully admit that I am not an expert on Spring Boot, I know roughly of what it does, but I do not see locking up Guacamole's code and/or releases in a Spring Boot only model as anything that would be an advantage to the project. > > That would make starting to use and develop guacamole much easier. > > I'm all for making it easier to use and develop, but I'm very cautious and usually opposed to moves that lock a certain project (Guacamole) into something else and make it more difficult for people to run in environments that don't match exactly what I happen to be doing. Mike, James, Carl, Luke - interested to hear your thoughts... -Nick
