[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [spaces-dev] 3.3, 3.4, or both?
|
ok, then I think we should have two update sites. One for the "frozen/
current" version for 3.3, and one for latest - that quite soon will
require Ganymede. Is that how you also see this?
Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx
On 5 apr 2008, at 17.59, Thomas Hallgren wrote:
Henrik Lindberg wrote:
I think we should at least tag the current implementation to at
least make it possible to branch at some later date if wanted.
Do we need to have two update sites if we simply want to freeze the
current release for 3.3 ?
It's the simplest way to do it. If we don't we need to improve the
build process so that we maintain an update site where we publish
multiple versions of its contained features (right now we simply
replace one site snapshot with another). All features must also have
constraints so that the update manager filters them out correctly.
It's doable of course, but is it worth the effort?
- thomas
Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx
On 5 apr 2008, at 11.11, Thomas Hallgren wrote:
It will become increasingly hard to maintain one single code-base
that will be compatible with both Eclipse 3.3.x and Eclipse 3.4.x.
That begs the question, do we want to be backward compatible with
Eclipse 3.3 or do we consider Spaces to be a new project that has
its first proper release when Ganymede is released in June?
Staying backward compatible will cause some overhead since we'll
need a separate branch and a separate update site.
- thomas
_______________________________________________
spaces-dev mailing list
spaces-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/spaces-dev
_______________________________________________
spaces-dev mailing list
spaces-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/spaces-dev
_______________________________________________
spaces-dev mailing list
spaces-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/spaces-dev
