3:32 p.m.
In order to keep Plugin versioning sane, we should discuss the actual rules
of our versioning strategy. From our meeting today, we discussed the
following possible initial rules:
- Using OSGI versioning system
- Plugins referencing older forge API should run on newer Forge versions
within the same N release for a version number N.x.x
- Plugins referencing newer forge API should not run on older Forge
versions within the same N release for a version number N.x.x
Thoughts? Would someone care to explain the OSGI versioning system?
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
4:24 p.m.
On 2012-03-14, at 10:32 AM, Lincoln Baxter, III wrote:
In order to keep Plugin versioning sane, we should discuss the actual
rules of our versioning strategy. From our meeting today, we discussed the following
possible initial rules:
Using OSGI versioning system
Plugins referencing older forge API should run on newer Forge versions within the same N
release for a version number N.x.x
Plugins referencing newer forge API should not run on older Forge versions within the
same N release for a version number N.x.x
I also think this should incorporate the
concept of 'binary compatibility' somehow - i.e. *running* on a given Forge
version vs *building* against a given Forge version. Rules can be more lax in the latter
case (some things may not build from scratch in face of API changes, but already built
versions may work.
Thoughts? Would someone care to explain the OSGI versioning system?
It's a form of Major.Minor.Micro.Qualifier - with qualifiers sorted
lexicographically.
Re: compatibility/versioning, I think that another set of rule you may want to take into
account is: http://apr.apache.org/versioning.html.
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
6:12 p.m.
see http://www.slideshare.net/pvanderlei/osgi-versioning-and-testing slide 10.
OSGI is major.minor.micro.qualifier
and it also defines what kind of things that breaks.
First half of the presentation is not OSGI specific and just outlines good practices and
how OSGI captures it.
Second half is osgi/eclipse specific concerning the tools that are available for it
which doesn't really apply since forge aren't using osgi.
But an interesting read ;)
/max
On Mar 14, 2012, at 4:24 PM, Marius Bogoevici wrote:
>
> Thoughts? Would someone care to explain the OSGI versioning system?
It's a form of Major.Minor.Micro.Qualifier - with qualifiers sorted
lexicographically.
Re: compatibility/versioning, I think that another set of rule you may want to take into
account is: http://apr.apache.org/versioning.html.
4424
days inactive
4425
days old
2 comments
3 participants
participants (3)
-
Lincoln Baxter, III -
Marius Bogoevici -
Max Rydahl Andersen