a branch per platform ...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

a branch per platform ...

Dale Henrichs
In my post on " Metacello and FileTree/Cypress" I know that I wasn't even clear in my own mind what I was trying to determine, but Stef's comments and questions plus some more thinking has lead me to being able to ask a simple question:

  Does it make sense to "require" platform branches when moving a project to git/github?

"Requiring platform branches" relates to how you will specify your package dependencies for Metacello ... without Metacello this discussion is moot.

"Requiring platform branches" does not mean that every project has to have a common/pharo/squeak/gemstone branch.

"Requiring platform branches" means that if your code runs _unchanged_ on only one platform (i.e., pharo1.3 specific), then you only need one branch (the master branch is the default). If your code runs _unchanged_ on 3 platforms (i.e., pharo, squeak, gemstone) then you only need one branch. If your code runs on 3 platforms, but requires changes to run on gemstone (i.e., it runs _unchanged_ on pharo and squeak)then you need two branches (master and gemstone). And so on...

We need to have ways of specifying which platforms are supported on a particular branch. Even if there is only one branch, we need to know which platforms it is expected to run _unchanged_ on.

The development scenario is that I start a NEW project that I expect to run unchanged on all platforms:

  - I declare that the supported platforms are pharo and squeak
  - I run my tests on the supported platforms
  - I announce the project
  - For the next release I add a feature that is specific to pharo
    with no intent to release this feature on squeak
  - I create a pharo branch.
  - on the master branch I change the supported platforms to squeak
  - on the pharo branch I change the supported platforms to pharo
  - on the pharo branch I add the pharo only feature
  - test and release and so on.

If you are moving an EXISTING project to git/github/metacello then you will go through a similar process:

  - If you _do not_ have platform dependencies in your code, you will put
    your packages into the filetree repository and convert your ConfigurationOf
    to the git form (yet to be determined)
  - If you _do_ have platform dependencies then you will start on the master
    branch and load the project into one of your supported images and save
    the code for the common packages to the master branch
  - Then you will create one branch per supported platform (the master branch is
    where the common code is saved) and save packages that are specific to that
    branch for each each branch
  - when you're done, you will merge the master branch into each of the platform
    branches to mark a point at which all branches share a feature base.
  - then you'll follow the sequence similar to that described in the "Guidelines for
    Contributing"[1] for the FileTree project

I think that this is a reasonable process, but that could just be me:) So I am again interested in more feedback ...

Now is the time to express concerns ... if "Requiring platform branches" seems reasonable then I can completely avoid going through the work of creating an interim VersionOf implementation and go straight to what I think will be pretty close to what we should be doing (the details of which will depend upon whether or not a VersionOf implementation is involved:)...

As far as process is concerned. The recent FileTree changes have brought FileTree in alignment with the VW STIG (Cypress) project and Bob Nemec is working a VAST implementation for Cypress which means we are at a stable point for FileTree ... If we are going to make any modifications to the package format they will be made after we've completed a trial period for FileTree and the Metacello Scripting API (Phase 1)... that way we can make one coordinated release all of the desired changes to the format before recommending use by a wider audience...

If I get the green light, I will be able to make short work the Metacello Scripting API spec and get on with the implementation...

Dale

[1] https://github.com/dalehenrich/filetree/blob/master/doc/Contribute.md#forkme