Re: [dali-dev] Dali and Public API changes

[Max Rydahl Andersen <max.andersen@xxxxxxxxxx>]

>>> How do your own adopters at Oracle do this?
> 
> I think there is a lot of variability on this among the entire adopter community.  Some adopters choose to build on top of a specific release train version of Eclipse, without trying to maintain compatibility with other versions within the same code base.  Where support for multiple release trains is needed in a particular release, multiple code streams and packages are used.  Some adopters have seen this cost as worthwhile for the adoption of rapidly improving and expanding components.

okey - so I read that as you are doing multiple code streams ? :)

>>> Is there any chance that latest Dali release can run on both 3.7 and 3.8/4.2 and we could do it that way ?
> (i.e. depend on Dali M7 from both 3.7 and 3.8 codebases)
> 
> Actually, you could potentially run our latest release (Dali 3.1 - Dec 2011) on both Eclipse 3.7 and 3.8.  There is some compatibility code in the 3.1 release to allow Dali clients to use the same code for 3.0 and 3.1.  This was done because 3.1 was not based on a new release train, but instead it was based on the same Indigo train.   This could not be done with 3.2M7.

okey, so in other words if we want to use/enable the new features in Juno with one code stream we can't - at least not for Dali.

> All of that said, this has made me think of something that we should be doing.  In addition to doing a new and noteworthy that covers end-user functionality, we need a new and noteworthy specifically for Dali adopters.  This would be a per milestone summary of the types of changes that will specifically benefit/be of interest to adopters.  This would more easily allow adopters to be aware of (and perhaps encourage participation in) some of the larger scale changes to our model.  It would go hand in hand with a migration guide to help adopters move to the new code.  This would be in addition to the existing weekly status emails.

+100

> This also raises the question of what we can do moving forward regarding a public API for Dali.  This has been a hot topic of late, and I can assure everyone that this will be a large discussion point for our planning meetings for Dali Kepler.    I would guess that some of you will be in attendance to ensure this is discussed. : )

Remind me when that is and I'll make all the attempts I can to be part or have someone be part of it.

> This is all a balancing act, and I hope we can find the right point on the scale to ensure that Dali continues to evolve and improve while making sure our adopters can benefit from those improvements.

Yes I know its a balancing act and I know how hard it is to encapsulate something as complex as JPA/JAXB behind a stable api.

What I hope is that the api for Juno is powerful/good enough to be used as an api for multiple releases and Dali can start doing similar tricks that is done in the platform of having multiple interfaces to avoid breaking existing clients.

/max