Issue #18169 has been updated by enebo (Thomas Enebo).


Perhaps a possible solution is when anyone edits the version of a default gem within CRuby they change the version of that gem to reflect it has not been released.  For example, if cgi-3.0.2 needs changes on first change make it 3.0.3-dev (in other words no gem authors should be putting a final release for anything other than synchronization of gems at the point of a CRuby release).  Release manager then will have an obvious marker that those gems have not been updated with the external gem source.  Once synced they remove the -dev.

I can think of more elaborate things (like writing a script to compare all gems source against their gem repos prior to release) but it really feels like the biggest problem here is not having an obvious workflow trigger that some work has not been done yet (e.g. syncing gems).



----------------------------------------
Bug #18169: Local copies of gemified libraries are being released out of sync with their gems
https://bugs.ruby-lang.org/issues/18169#change-93832

* Author: headius (Charles Nutter)
* Status: Assigned
* Priority: Normal
* Assignee: hsbt (Hiroshi SHIBATA)
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
The CRuby codebase includes a number of libraries that have been gemified, more and more with each release. Unfortunately, these libraries are continually out of sync with both their home repositories and their released gems.

The problem lies in the fact that CRuby keeps a local copy of these libraries within the CRuby git repository, and allows committers to make changes either in the CRuby repository or in the gem's home repository. This has led to many releases of Ruby shipping code that **does not correspond to any released version of the related gem**.

I have filed several issues about this but the root cause has not been addressed:

* https://github.com/ruby/ostruct/issues/11
* https://github.com/ruby/matrix/issues/12
* https://github.com/ruby/prime/issues/11
* https://github.com/ruby/webrick/issues/48
* https://github.com/ruby/rdoc/issues/835
* https://github.com/ruby/rexml/issues/79
* https://github.com/ruby/fileutils/issues/59
* https://github.com/ruby/ostruct/issues/31

If these gems are to live on their own as standalone libraries/gems then one of two things must happen:

* All changes to them must go into their repositories. This would be the cleanest option. CRuby would, like JRuby, source these libraries directly from released gems, and no copies of their sources would be versioned in the CRuby git repository.

OR

* CRuby-local changes to these libraries must be prohibited from being released unless there is a corresponding gem release. This would require automated or manual auditing at release time, to ensure that the claimed gem version actually corresponds to the sources being shipped.

In addition to making it impossible for external users of these gems to match CRuby releases, there are more serious implications:

* These hybrid intra-version changes to these libraries cannot be audited to a specific gem release. This could affect stability and security when users attempt to sync their local gem sets to the ones that shipped in a given version of Ruby.
* Security fixes have gone out in CRuby releases but no corresponding x.x.y or x.x.x.y security release of the gem was released. This prevents users from fixing the security issue locally without either upgrading CRuby or also including new functionality changes (which may or may not work on the current version of Ruby).

See the rexml issue above for one example of the security problem. Until the gem was released, it was not possible to install any gem version with the security fix without upgrading functionality elsewhere in rexml.

I believe it is time for CRuby to stop making changes to gemified libraries directly in the CRuby repository. These libraries have their own gems, repositories, and issue trackers, and that is where they should be maintained.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>