On Thursday, January 9, 2014 9:03:07 AM UTC+1, Antje Janosch wrote:
> Hello,
> I only did basic stuff with git so far (not even branching), but now I 
> need to solve this:
> I have a repository on github with some software development. This stuff 
> is an extension for another software. Now, I'd like to create a branch for 
> each release of this other software to ensure that my development fits with 
> a certain version of this other software.
> How would I have to do it (I'm using eGit in Eclipse)?
> I read bits and pieces about remote tracking branches. But I don't really 
> get if that is what I need... 

One mental exercise you can do is to not think about the remote/local 
aspects for the time being. Just focus on repositories you've got locally.

So, if I understand you correctly, you have built an extension for some 
larger project for which you have no control. Let's say for example, your 
building a plugin for Wordpress called "extenso".

So, you've got two repositories: wordpress.git and extenso.git.

Now, every now and then, Wordpress will release new versions, and by doing 
so they will tag in their repo (I'm just making up version numbers here):

  tag: 1.0
  tag: 1.1
  tag: 2.0

Now, you're developing your plugin in a branch called master:

  branch: master

You choose to ignore older versions of Wordpress, focusing on being 
compatible with Wordpress 2.0. After some development time, you deem your 
extension worthy of a release, hence you release for the first time, based 
on the last commit off master:

  branch: master
  tag: 1.0

(note, below I'll ignore the aspect of branches, as you'll only be working 
in the master branch)

So when people consider your extension, how do they know whether it's 
compatible with their Wordpress instances, which may be running older 
versions? Well, this is a cultural thing. Most projects simply write this 
in a README file:

Extenso is a Wordpress plugin that does great things!

Requires Wordpress 2.0 or higher.

(Or more specifically: extenso 1.0 has been tested on Wordpress 2.0, but we 
assume it will work on all 2.x versions because we only rely on external 
behavior which should not change in minor releases of Wordpress.)
============= END OF README ===========

Other projects have metadata files that can programmatically instruct the 
embedding product (Wordpress) which versions they require. In Java land we 
have Maven dependency versions. Tools like Jenkins have a plugin center 
that manages version compatibility, etc. You need to see what is typical in 
your context.

Now, let's carry on for a while to see what happens over time. Assume we'll 
just stick to using the README for declaring dependency versions.

Wordpress after some time releases a new version, 2.1:

  tag: 1.0
  tag: 1.1
  tag: 2.0
  tag: 2.1

Now, something horrible happens: It turns out that your extension is based 
on some internal Wordpress logic that they changed in their 2.1 release! 
This means you quickly have to get a fix out the door and warn users. So 
you fix the problem (while still remaining backward compatible with 
Wordpress 2.0), and edit the README for the 1.1 release:

Extenso is a Wordpress plugin that does great things!

Current version (1.1) requires Wordpress 2.0 or higher.

NOTE: extenso 1.0 only works with Wordpress 2.0. Users are recommended 
upgrading to extenso 1.1 asap!
============= END OF README ===========

Perhaps over time, as more version dependency discrepancies appear, you 
make some dependency version table in the README or something. Whatever 
makes it clearer for your users which versions they should use.

So, my main point of this long story is that the versioning of your product 
can be done separate from that of the "containing project", as long as you 
make clear to the users what versions they should be using.

BUT there are other ways to do it, of course. Another way is to mirror 
version numbers in the plugin: If you choose this way, you should tag like 
this instead:

  tag: 2.0 (works with Wordpress 2.1)
  tag: 2.1 (works with Wordpress 2.1)

Of course, the annoying thing with this approach is that every time 
Wordpress makes a release, you have to make one too, even if you have no 
changes to make. A workaround would be to release a "2.x" version, which 
you promise will work with all 2.x versions of Wordpress. But as 
illustrated above, this can be a dangerous prediction to make.

A third way is to physically link the two projects together by using Git 
submodules. Now, I'll put it short that this is a advanced albeit "safe" 
way to ensure dependency version compatibility.

Let's say that Extenso totally wraps Wordpress in such a way that people 
think they are running Extenso as the main product, and Wordpress is just 
an underlying implementation detail. So you include the whole Wordpress 
source code in extenso as a submodule:

extenso.git (version 1.0)
     wordpress.git: 2.0 [submodule]

When the time comes to upgrade to wordpress 2.1, you upgrade the submodule 
to point to wordpress 2.1, and make a new release:

extenso.git (version 1.1)
     wordpress.git: 2.1 [submodule]

For 95% of the projects out there, this last project is probably overkill. 
But perhaps it's interesting to have seen this perspective.

Now, I'm not sure if the above explanation was something you were looking 
for (it's actually very little Git specific, as you can see). Do you have 
some more concrete questions as a follow-up to this?

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to