Databases
StackOverflow2013
Postsdbo
POHandling versioning for a large Ruby project split into subprojects
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POHandling versioning for a large Ruby project split into subprojects
    primarykey
    data
    text
    <p><strong>TL;DR</strong> - <em>Large project has many plugins which cause automated tests to fail way too often. I’d like to split this project into a core repo and an extensions repo, but how?</em></p> <p>I have a large project (<a href="http://nanoc.ws/" rel="nofollow">nanoc</a>) that has a plethora of plug-ins, each with their own dependencies. For example:</p> <ul> <li>A <code>handlebars</code> plugin, which depends on <code>therubyracer</code></li> <li>A HTML validator plugin, which calls an external web service</li> </ul> <p>A lot of these plugins occasionally fail:</p> <ul> <li>fail to build (e.g. <code>therubyracer</code> or <code>nokogiri</code>);</li> <li>produce output that is not expected by nanoc;</li> <li>call web services (e.g. HTML/CSS validator) that are down, throttling requests, etc.</li> </ul> <p>The continuous integration service used by nanoc (<a href="https://travis-ci.org/" rel="nofollow">Travis</a>) very regularly reports errors. 95% of these errors are caused by plugins.</p> <p>This makes the continuous integration test results somewhat useless. I’ve grown to ignore “error” build statuses and just assume something went wrong in a plugin. This is clearly not a good situation.</p> <p>I want to split up the project in two parts:</p> <ul> <li>a <strong>core</strong> repository+gem that contains the basic code for the project, without the plugins, and</li> <li>a <strong>plugins</strong> repository+gem that contains every single plugin.</li> </ul> <p>I would work on <em>core</em> most of the time, occasionally updating the <em>plugins</em> repository so that it matches the work done in <em>core</em> (although usually, the changes in <em>core</em> will not affect <em>plugins</em>).</p> <p>This seems like a reasonable approach, but I have some reservations:</p> <ul> <li>I have no good idea how to handle versioning. Should the same version be used for both gems, always? This may clash with the <a href="http://semver.org/" rel="nofollow">Semantic Version</a> approach I am using now.</li> <li>Should there be a single plugins repository, or should each plugin get its own repository? This may make versioning even harder.</li> <li>I want to release new plugins quickly, so that people don’t have to wait for a new feature release before they can use the new plugins. Versioning is even more difficult here.</li> </ul> <p>Thoughts and ideas are appreciated.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USddfreyne
    1. USddfreyne
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload