[erlang-questions] modular otp concerns

Björn-Egil Dahlberg <>
Tue Feb 18 19:02:17 CET 2014


On 2014-02-18 18:46, Michael Truog wrote:
> On 02/18/2014 09:30 AM, Björn-Egil Dahlberg wrote:
>> If/when we split the OTP repository, and this split should be on the 
>> level where we have specific versions i.e. on application level. It 
>> has solve the issue of easy delivery of new patches and release on 
>> these specific applications. Some have voiced a concern that it will 
>> simply be to many repos and we should instead group them, i.e. Orber 
>> + cos* etc. I say fine, if so then those applications should have one 
>> version (and be a single application). One versioned entity per 
>> repository thank you. 
> My main concern is: if the OTP repository is split, we still need the 
> concept of a "version set", so a set of versions for all of OTP that 
> are known to work together, just to help people avoid any potential 
> for instability.  With that concept in place, it shouldn't be a 
> problem either way, and you are probably aware of the issue, but I 
> wanted to mention it due to the added complexity that not having a 
> "version set" concept can cause.  If you don't have that concept, of 
> versions grouped into a release, basically, then you run into a 
> combinatorial problem during testing, which makes testing take longer 
> (i.e., for all end-users).
>
>

I'm aware. The "set" you talk about would ideally be controlled by the 
application dependencies.

But OTP releases would be the set you talk about though and a top repo, 
i.e. otp would control the set. I imagine that we would still have 
releases just like today with a set of applications that we have tested 
together.

As for patches, those are tested with the dependencies specified, 
typically with those applications in the previous release. It would have 
the same stability as before.

It is unfortunate that this debate got started now. I have actually zero 
time to spend on it .. i'll can do is watch it spin into another dimension.

// Björn-Egil





More information about the erlang-questions mailing list