[erlang-questions] modular otp concerns
Björn-Egil Dahlberg
egil@REDACTED
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