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(a)gmail.com&gt; wrote: > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

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(a)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(a)redhat.com&gt;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(a)gmail.com&gt; wrote: >> > _______________________________________________ >> > forge-dev mailing list >> > forge-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/forge-dev >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Yes, let's create a JIRA for this! Thanks, Ivan! On Tue, Mar 13, 2012 at 6:38 PM, Ivan St. Ivanov <ivan.st.ivanov(a)gmail.com > wrote: > 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)gmail.com&gt; wrote: >>>> > _______________________________________________ >>>> > forge-dev mailing list >>>> > forge-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/forge-dev >>>> >>>> >>>> _______________________________________________ >>>> forge-dev mailing list >>>> forge-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/forge-dev >>>> >>> >>> >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> > > _______________________________________________ > forge-dev mailing list > forge-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Strange! Everyone should have access! I hate JIRA sometimes... try logging out then back in again? ~Lincoln On Wed, Mar 14, 2012 at 11:49 AM, Ivan St. Ivanov < ivan.st.ivanov(a)gmail.com&gt; wrote: > I'm afraid I don't have permissions for that > > > On Wed, Mar 14, 2012 at 5:17 PM, Lincoln Baxter, III < > lincolnbaxter(a)gmail.com&gt; wrote: > >> Yes, let's create a JIRA for this! Thanks, Ivan! >> >> >> On Tue, Mar 13, 2012 at 6:38 PM, Ivan St. Ivanov < >> ivan.st.ivanov(a)gmail.com&gt; wrote: >> >>> 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)redhat.com&gt; 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(a)gmail.com&gt; wrote: >>>>>> > _______________________________________________ >>>>>> > forge-dev mailing list >>>>>> > forge-dev(a)lists.jboss.org >>>>>> > https://lists.jboss.org/mailman/listinfo/forge-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> forge-dev mailing list >>>>>> forge-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> forge-dev mailing list >>>>> forge-dev(a)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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/forge-dev >>>> >>>> >>> >>> _______________________________________________ >>> forge-dev mailing list >>> forge-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> > > _______________________________________________ > forge-dev mailing list > forge-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev