Excuse me, i mean multi-release package. We already have release directives
in plugin metadata.yaml that defines releases compatible with the plugin.
As far as i understand "multi-release package" suppose ability to define
custom configuration/code for each of this releases.
On Fri, Feb 12, 2016
>> We have package format <=4.0 where all files have fixed names and
locations. This is the defaults.
The thing is for 5.0 there should be no default, those fields from now on
should be specified explicitly.
>> Igor want to provide multi-package
I'm not familiar with this idea, could you please
On Fri, Feb 12, 2016 at 2:03 PM, Evgeniy L wrote:
> Ilya,
>
> What do you mean by "default"? From the data format I see that we don't
> "override defaults" we specify the data for specific release, the way it
> was always done for deployment scripts and repositories.
>
>
We have package format <=
Ilya,
What do you mean by "default"? From the data format I see that we don't
"override defaults" we specify the data for specific release, the way it
was always done for deployment scripts and repositories.
I don't see any reasons to complicate format even more and to have some
things which are
On Fri, Feb 12, 2016 at 11:47 AM, Evgeniy L wrote:
> Ilya,
>
> >> My opinion that i've seen no example of multiple software of plugins
> versions shipped in one package or other form of bundle. Its not a common
> practice.
>
> With plugins we extend Fuel capabilities, which supports multiple
> op
Stanislaw B.,
You're somehow contradicting in your statements. However, taking into
account your's -
> Both of these approaches can be used, so I'm against forcing plugin
> developers to use just one approach.
I can conclude that you support idea of having multi-release plugins?
Because no one c
>>With plugins we extend Fuel capabilities, which supports multiple
operating system releases, so it's absolutely natural to extend multiple
releases at the same time.
It is okay for me when we talk about different operating system release,
but initial question was about different Fuel and OpenStac
Ilya,
>> My opinion that i've seen no example of multiple software of plugins
versions shipped in one package or other form of bundle. Its not a common
practice.
With plugins we extend Fuel capabilities, which supports multiple operating
system releases, so it's absolutely natural to extend multi
r/YACL/YAQL/
On Thu, Feb 11, 2016 at 9:35 PM, Ilya Kutukov wrote:
> My opinion that i've seen no example of multiple software of plugins
> versions shipped in one package or other form of bundle. Its not a common
> practice.
>
> Anyway we need to provide ability to override paths in manifest
> (
My opinion that i've seen no example of multiple software of plugins
versions shipped in one package or other form of bundle. Its not a common
practice.
Anyway we need to provide ability to override paths in manifest
(metadata.yaml).
So the plugin developers could use this approaches to provide m
Hi,
On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky
wrote:
> Hey folks,
>
> The original idea is to provide a way to build plugin that are
> compatible with few releases. It makes sense to me, cause it looks
> awful if you need to maintain different branches for different Fuel
> releases and th
Sorry for the typo "s/I can shade more light/I can shed more light/"
On Thu, Feb 11, 2016 at 1:51 PM, Evgeniy L wrote:
> Hi,
>
> As an author of this part of pluggable architecture I can shade more light
> on why it was implemented this way and why it's valuable to continue
> supporting multi-re
Hi,
As an author of this part of pluggable architecture I can shade more light
on why it was implemented this way and why it's valuable to continue
supporting multi-release feature.
At the time it was implemented Fuel officially was supporting both Ubuntu
and CentOS, in order to simplify plugins
Hey folks,
The original idea is to provide a way to build plugin that are
compatible with few releases. It makes sense to me, cause it looks
awful if you need to maintain different branches for different Fuel
releases and there's no difference in the sources. In that case, each
bugfix to deploymen
I agree with Stas, one rpm - one version.
But plugin builder allows to specify several releases as compatible. The
deployment tasks and repositories can be specified per release, at the same
time the deployment graph is one for all releases.
Currently it looks like half-implemented feature. Can
On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko
wrote:
> +1 to Stas, supplanting VCS branches with code duplication is a path to
> madness and despair. The dubious benefits of a cross-release backwards
> compatible plugin binary are not worth the code and infra technical debt
> that such approa
+1 to Stas, supplanting VCS branches with code duplication is a path to
madness and despair. The dubious benefits of a cross-release backwards
compatible plugin binary are not worth the code and infra technical debt
that such approach would accrue over time.
On Wed, Feb 10, 2016 at 07:36:30PM +030
It changes mostly nothing for case of furious plugin development when big
parts of code changed from one release to another.
You will have 6 different deployment_tasks directories and 30 a little bit
different files in root directory of plugin. Also you forgot about
repositories directory (+6 at l
18 matches
Mail list logo