Re: [cross-project-issues-dev] Best practices on versioning

[Nick Boldt <codeslave@xxxxxxxxxx>]

Thanks, Rich, Doug.

After we finish with 2.2, we plan to step up to the .100 numbering system
(http://www.eclipse.org/equinox/documents/plugin-versioning.html) so that
we'll only reversion plugins when they actually change.

As to a unified build, I'm all for it. Or at the very least, more
cross-project communication automation. (RSS feeds, anyone?)  ;-)

Cheers,

--
Nick Boldt :: Software Developer
Eclipse Modeling Framework :: http://eclipse.org/emf
IBM Toronto Lab, 8200 Warden Ave., D3/R8R/8200/MKM, Markham, L6G 1C7.
905/413/4308 || codeslave@xxxxxxxxxx && Nick Boldt/Toronto/IBM@IBMCA


Friday, April 28, 2006 10:14 AM
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc:
From: Richard Gronback <richard.gronback@xxxxxxxxxxx>
Subject: Re: [cross-project-issues-dev] Best practices on versioning


Perhaps this is something we can strive for incorporating into the next
Callisto (whatever it's called), meaning that if you sign up for
Callisto, you're also signing up to participate in (read: contribute to)
a unified build?

- Rich

Doug Schaefer wrote:
>
> To take some heat off EMF J, we do the same in the CDT. What is best
> practices for some is not as good for others. The CDT does not have a
> release engineering team. In fact, I am the CDT release engineer.
> Since I have many hats, I do not have much time to spend on writing
> build scripts and am reluctant to change them. So for us, not using
> the releng tools and simply tagging and building all the plugins every
> build was easy to do, it works, and I don?t have the time right now to
> change them. This is also why I am against the pack200 thing BTW.
>
> Now as the next simultaneous release rolls around again next year, I
> think this is one area where we could really reduce duplication in the
> projects and streamline things. I would like to propose that we have
> one release engineering team, with maybe participants from various
> projects, working on one single set of build scripts and a single
> simultaneous build. This would solve a lot of problems, including the
> lag we have between Platform build and Callisto release, and it would
> make it easier for us to line up with ?best practices?. On the
> negative side, there is much more chance for these builds to be busted
> as API changes occur in the lower bits, but then I think that would
> also force the lower bit teams and the upper bit teams to communicate
> more.
>
> Any, just a thought and sorry for not following ?best practices?.
>
> Cheers,
>
> Doug Schaefer, QNX Software Systems
>
> Eclipse CDT Project Lead, Tools PMC member
>
> http://cdtdoug.blogspot.com
>
> ------------------------------------------------------------------------
>
> *From:* cross-project-issues-dev-bounces@xxxxxxxxxxx
> [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] *On Behalf Of
> *David M Williams
> *Sent:* Friday, April 28, 2006 12:23 AM
> *To:* cross-project-issues-dev@xxxxxxxxxxx
> *Subject:* [cross-project-issues-dev] Best practices on versioning
>
>
> I thought I'd post this here, for a "wider" education (either mine or
> others :)
>
> I've noticed one project (EMF) that appears to version all their
> features and all their plugins, in the 4th place qualifier field,
> to match the date and time of their builds. On the one hand, this is
> nice to tell what goes-with-what in directory lists, but its counter to
> "best practices" on feature and plugin versioning, right? Shouldn't
> features and plugin versions (and qualifiers) change only when the
> code really changes? Perhaps EMF really does change each and every one
> of their features and plugins each build ...
> nah, I'm sure they don't do that. So .. is this a long term plan? Just
> a short term tactic?
>
> I thought I'd ask here, publically, in case there is a reason for this
> I'm not aware of ... so we can all be educated.
> The problem this strategy poses is that with something like update
> manager, it means users/developers might end up (re) installing code that
> hasn't really changed. So .. sure EMF is a tiny project :) ... but, I
> hope this doesn't become widespread practice, or the new
> versioning rules won't accomplish as much as it could. For one
> documented scheme on versioning rules see
> http://www.eclipse.org/equinox/documents/plugin-versioning.html
> We in WTP are attempting to following this too.
> Do other projects have other, different schemes?
>
> And, I hope well known, I don't mean to "pick" on EMF .. I have not
> really looked at many others projects schemes, but just noticed
> EMF's practice, and thought I'd ask here in the interest of
> development in the open.
>
> Thanks in advance for any clarifications.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev