mike-jumper commented on issue #407: GUACAMOLE-805: Handle OpenID "id_token" 
parameter regardless of location in URL fragment.
URL: https://github.com/apache/guacamole-client/pull/407#issuecomment-498383456
 
 
   Current process
   ----------------------
   
   At any given time, there are no more than two possible releases in flight:
   
   1. A release whose scope has been finalized (`staging/*`)
   2. A release whose scope has not yet been finalized (`master`)
   
   Whether the project decides to release the next release as 1.1.1 rather than 
1.2.0 is a decision to be made following 1.1.0. It would be best if you don't 
read into the version number any further than a cosmetic representation of the 
content and compatibility of the release; it does not affect timing.
   
   Overall:
   
   * Releases are cut when possible. Timing depends only on testing and process 
and consensus, which all depend on the availability of the volunteers that 
contribute to the project, myself included. It has nothing to do with the 
version number.
   * Scope of the `staging/*` release is set in stone. Feature creep is a sure 
way to kill a release.
   * The version numbering will be ultimately decided when the scope of the 
next release is finalized. The decision of what will go into that release is 
not a decision to be made now. That decision happens after the next release.
   
   Changes to the current process
   -----------------------------------------
   
   As noted in the thread you link to, there has been occasional discussion of 
migrating to a process that would allow for bugfix releases. We don't currently 
have such a process. A lot of thought and preparation would need to go into 
that decision. It's not out of the question.
   
   What you can do
   ----------------------
   
   Contribute. Be involved in the community.
   
   A better place for this would have been the mailing list, where the rest of 
the community can be present in the discussion. Commenting only on JIRA or 
GitHub reaches a much smaller audience. Unless the discussion is extremely 
directly related to the development at hand, this will just drain the energy of 
the few that can see your comments. If this PR had not yet been merged and you 
found an issue with the change, this would have been a good place for that. If 
the merged code did not actually solve the issue and you believe the bug must 
be reopened, JIRA would be appropriate. It's not the place to discuss release 
policy.
   
   If you have feedback regarding the next release, constructive ideas for 
changes to process, etc., the best place for that is the mailing list. The dev@ 
list is where all development discussion occurs, and that list will be the home 
of the thread that will be opened following 1.1.0 to discuss release scope.
   
   http://guacamole.apache.org/release-procedures-part1/
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

Reply via email to