Hi Lincoln,

Yes, that's the source for email addresses! We were discussing about notifying authors just of the so called "blessed" plugins, so maybe the central repository yaml is the right collection of those plugins.

Should I create the JIRA?

Cheers,
Ivan

P.S. Tomorrow I am skipping the forge meeting. I have another appointment at work

On Mon, Mar 12, 2012 at 3:39 PM, Lincoln Baxter, III <lincolnbaxter@gmail.com> wrote:
Hey Ivan,

I agree with your summary.

I think that we should update Forge's version resolution during installation to be a little more lenient (I believe Paul has volunteered for this?)

 But it does make sense to notify authors of a new release. Actually, we already have a great solution for keeping track of who needs to be notified! The central plugin repository itself has the information we need! (Or it should, in order to be listed, contain a valid email address of the plugin author.)

What do you think?
~Lincoln


On Sun, Mar 11, 2012 at 2:18 PM, Ivan St. Ivanov <ivan.st.ivanov@gmail.com> wrote:
Hi folks,

On the meeting on Wednesday I took the action item to write a JIRA issue for creating automated routine that checks a set of plugins for their versions and emails their authors if that version is different than that of Forge.

I'd like to summarize after looking at this discussion. I assume that we should first change the way Forge resolves the version to install. I agree that we should allow installing plugins which major version (expressed in tag or branch) is the same as that of Forge. So, if Forge is 1.2.3, then all 1.x.y are allowed (1.1.5, 1.2.3, even 1.3.0), but not 2.0.1. I also agree that there should be an option for the user to decide which of the allowed versions to apply with the highest as default (or the "closest" to Forge's version?).

As for my action item, I think I should still create it (it's still valid). Do you think that something like this is fine: "Create a routine, executed by the build server, that checks a predefined set of Forge plugins for version consistency with Forge core. In order to satisfy this check, for each major version of the core there should be at least one plugin branch or tag that specifies the same major version. If the check fails, the plugin author should receive an email asking them to fix the inconcistency."

As for Dan's and Max's proposals, I think we should consider them only if we decide that we need more complex version rules.

Regards,
Ivan

On Fri, Mar 9, 2012 at 2:44 AM, Max Rydahl Andersen <manderse@redhat.com> wrote:

if you are going that route - checkout OSGI versioning rules/syntax.

That has good defaults and deterministic version ranges

/max

On Mar 8, 2012, at 10:55 PM, Dan Allen wrote:

> Although it has a slightly different focus, I advise reading up on Bundler, the Ruby library versioning tool created by Yehuda Katz to bring sanity to rails plugins.
>
> It has an interesting version symbol to indicate upgrading along a major version:
>
> ~> 1.1.0
>
> That will allow 1.2.0, but not 2.0.0.
>
> Bundler also has the idea of version locking across the transitive closure.
>
> --
> Sent from my CyanogenMod-powered
> Android device, an open platform for
> carriers, developers and consumers.
>
> On Mar 8, 2012 10:21 AM, "Lincoln Baxter, III" <lincolnbaxter@gmail.com> wrote:
> _______________________________________________
> forge-dev mailing list
> forge-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev


_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev


_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev




--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"

_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev