[erlang-questions] A plead to use tags (or equivalent in your SCM system)

Torben Hoffmann torben.lehoff@REDACTED
Wed Apr 25 11:47:33 CEST 2012



On 25/4/12 11:39 , JD Bothma wrote:
> I think, at the very least, if you write something with rebar
> dependencies and the dependency repos aren't tagged, just use the hash of
> the change you're testing on. That's exactly the version that you
> believe to work.
>
> Sure, it's even better if everyone tags, they're more meaningful (I
> didn't even read about semantic versioning), but at the very least, I
> wouldn't want to end up with a moving target on some nested dependency
> just because one of my dependencies depend on someone else's master
> branch.
>
> You don't need to fork to have a stable dependency, you just use
>
> {deps, [{openid, ".*", {git,
> "https://github.com/brendonh/erl_openid.git", "ed8688d"}}]}.
Very true and I do that as well.
I just have this paranoia that I want to be sure that I have a fork of a 
dependency in case the author removes it. I have not personally been 
burned by this, but I would rather be safe than sorry ;-)

Cheers,
Torben

>
> instead of
>
> {deps, [{openid, ".*", {git,
> "https://github.com/brendonh/erl_openid.git", "master"}}]}
>
> JD
>
> On 25 April 2012 11:30, Torben Hoffmann<torben.lehoff@REDACTED>  wrote:
>> Hi!
>>
>> I might be a bit paranoid, but after loosing half a day due to an "update"
>> to a dependency given with {branch, "master"} I have resorted to the
>> following approach: I fork all the dependencies so that I am in control if I
>> cannot get a proper tag from the dependency itself.
>>
>> This means that:
>>
>> I control when to take in new stuff.
>> I can add my own tags to ease upgrades.
>> If the author removes his repo I still have access to the source.
>>
>> The main problem is that version numbering is not so popular these days -
>> what's the point when you have a sha?
>> Well, it harder to say intelligent things about the magnitude of a change
>> from looking at the sha compared to a version number that follows semantic
>> versioning (semver.org).
>>
>> With semantic versioning you know that a change to the major number will -
>> at the very least - require serious investigation before you can be sure
>> that your code with work with the updated dependency. And so on.
>>
>> It is actually easy to do semver with git - just tag your code.
>> But easy is not enough to get people to do this. Unfortunately.
>>
>> I am of the opinion that it becomes easier to re-use software that uses
>> semver - you get some info from the version number and people that takes the
>> time to do proper semver knows about software maintenance, which speaks
>> volumes for their code.
>>
>> Cheers,
>> Torben
>>
>>
>> On 24/4/12 21:43 , Heinz N. Gies wrote:
>>
>> Hi I've noticed that a lot of libraires depend on bleeding edge data I kind
>> of find that disturbing it makes maintaining a stable environment close to
>> impossible since one never knows
>>
>>
>> what I mean are lines like this:
>>
>> {alog, ".*", {git, "https://github.com/siberian-fast-food/alogger.git",
>> {branch, "master"}}}
>>
>> now if the alogger people push a breaking change your application breaks
>> when depending on it, even worst if you don't even use alogger yourself but
>> a library you use uses it a change in alogger would break your application
>> without you having direct influence on it :(.
>>
>> So what I'd love to ask people who maintain libraries is use dependencies
>> that have a fixed version and tag your own versions so people can do the
>> same when using your stuff - please?
>>
>> Regards,
>> Heinz
>>
>> PS: I just choose alogger as an example since it was the first I found - I
>> love the thing :)
>>
>> --
>> Heinz N. Gies
>> heinz@REDACTED
>> http://licenser.net
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>> --
>> http://www.linkedin.com/in/torbenhoffmann
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-- 
http://www.linkedin.com/in/torbenhoffmann




More information about the erlang-questions mailing list