[Framework-Team] plone 4 only branches

Discussion:

Nathan Van Gheem

2015-01-26 05:24:23 UTC

Hi All,

I'd like to merge plone.app.widgets into all of other plone packages for
plone 5.

In doing so, I need to create some plone 4 only branches for
plone.app.dexterity and plone.app.contenttypes.

Any objections?

Also, what does everything think about Archetypes and plone.app.widgets.
Should that code be merged as well or do we just start ignoring Archetypes
in plone 5 a bit?

-Nathan

David Glick (Plone)

2015-01-26 05:33:14 UTC

Permalink

Post by Nathan Van Gheem
Hi All,
I'd like to merge plone.app.widgets into all of other plone packages
for plone 5.
In doing so, I need to create some plone 4 only branches for
plone.app.dexterity and plone.app.contenttypes.
Any objections?

I don't really understand the benefit of spending effort to move the
code. Is there an important reason I'm forgetting?

Post by Nathan Van Gheem
Also, what does everything think about Archetypes and
plone.app.widgets. Should that code be merged as well or do we just
start ignoring Archetypes in plone 5 a bit?

I think if we ignore Archetypes in Plone 5, it will significantly
discourage users with custom AT content types from upgrading to Plone 5.

Nathan Van Gheem

2015-01-26 05:34:49 UTC

Permalink

Post by Nathan Van Gheem
Hi All,
I'd like to merge plone.app.widgets into all of other plone packages for
plone 5.
In doing so, I need to create some plone 4 only branches for
plone.app.dexterity and plone.app.contenttypes.
Any objections?

I don't really understand the benefit of spending effort to move the code.
Is there an important reason I'm forgetting?

plone.app.widgets overrides things in other packages to work so it's a bit
of indirection. I'd like to cut off plone.app.widgets and whoever wants to
maintain it for plone 4 can if they care to.

Post by Nathan Van Gheem
Also, what does everything think about Archetypes and plone.app.widgets.
Should that code be merged as well or do we just start ignoring Archetypes
in plone 5 a bit?
I think if we ignore Archetypes in Plone 5, it will significantly

discourage users with custom AT content types from upgrading to Plone 5.

Alright, we might need a branch for Archetypes also then :)

_______________________________________________
Framework-Team mailing list
https://lists.plone.org/mailman/listinfo/plone-framework-team

--
Nathan Van Gheem
Solutions Architect
Wildcard Corp

David Glick (Plone)

2015-01-26 05:42:16 UTC

Permalink

On Sun, Jan 25, 2015 at 11:33 PM, David Glick (Plone)
Hi All,
I'd like to merge plone.app.widgets into all of other plone
packages for plone 5.
In doing so, I need to create some plone 4 only branches for
plone.app.dexterity and plone.app.contenttypes.
Any objections?
I don't really understand the benefit of spending effort to move
the code. Is there an important reason I'm forgetting?
plone.app.widgets overrides things in other packages to work so it's a
bit of indirection. I'd like to cut off plone.app.widgets and whoever
wants to maintain it for plone 4 can if they care to.

Okay. I agree it would be ideal to avoid those overrides, although it
maybe should be considered lower priority than fixing bugs in Plone 5.

It looks like we already have branches for these packages -- Plone 4.3
is using the 2.0.x branch of plone.app.dexterity and the 1.1.x branch of
plone.app.contenttypes (at least according to sources.cfg in
buildout.coredev).

Also, what does everything think about Archetypes and
plone.app.widgets. Should that code be merged as well or do we
just start ignoring Archetypes in plone 5 a bit?
I think if we ignore Archetypes in Plone 5, it will significantly
discourage users with custom AT content types from upgrading to Plone 5.
Alright, we might need a branch for Archetypes also then :)

Also already exists -- Plone 4.3 uses the 1.9.x branch of
Products.Archetypes.

Nathan Van Gheem

2015-01-26 05:44:22 UTC

Permalink

ahh cool. I was just reading the docs and didn't notice any specifics about
that.

On Sun, Jan 25, 2015 at 11:33 PM, David Glick (Plone) <

Post by David Glick (Plone)

Post by Nathan Van Gheem
Hi All,
I'd like to merge plone.app.widgets into all of other plone packages for
plone 5.
In doing so, I need to create some plone 4 only branches for
plone.app.dexterity and plone.app.contenttypes.
Any objections?

I don't really understand the benefit of spending effort to move the
code. Is there an important reason I'm forgetting?

plone.app.widgets overrides things in other packages to work so it's a bit
of indirection. I'd like to cut off plone.app.widgets and whoever wants to
maintain it for plone 4 can if they care to.
Okay. I agree it would be ideal to avoid those overrides, although it
maybe should be considered lower priority than fixing bugs in Plone 5.
It looks like we already have branches for these packages -- Plone 4.3 is
using the 2.0.x branch of plone.app.dexterity and the 1.1.x branch of
plone.app.contenttypes (at least according to sources.cfg in
buildout.coredev).

Post by David Glick (Plone)

discourage users with custom AT content types from upgrading to Plone 5.

Alright, we might need a branch for Archetypes also then :)
Also already exists -- Plone 4.3 uses the 1.9.x branch of
Products.Archetypes.
_______________________________________________
Framework-Team mailing list
https://lists.plone.org/mailman/listinfo/plone-framework-team

--
Nathan Van Gheem
Solutions Architect
Wildcard Corp

Nathan Van Gheem

2015-01-26 06:00:34 UTC

Permalink

We could keep most of plone.app.widgets and just move all override stuff
into other packages(at_bbb.py, dx_bbb.py, skins). I'd then also just cut a
plone 4 only branch of plone.app.widgets.

Sound better?

Post by Nathan Van Gheem
ahh cool. I was just reading the docs and didn't notice any specifics
about that.
On Sun, Jan 25, 2015 at 11:42 PM, David Glick (Plone) <

On Sun, Jan 25, 2015 at 11:33 PM, David Glick (Plone) <

Post by David Glick (Plone)

I don't really understand the benefit of spending effort to move the
code. Is there an important reason I'm forgetting?

plone.app.widgets overrides things in other packages to work so it's a
bit of indirection. I'd like to cut off plone.app.widgets and whoever wants
to maintain it for plone 4 can if they care to.
Okay. I agree it would be ideal to avoid those overrides, although it
maybe should be considered lower priority than fixing bugs in Plone 5.
It looks like we already have branches for these packages -- Plone 4.3 is
using the 2.0.x branch of plone.app.dexterity and the 1.1.x branch of
plone.app.contenttypes (at least according to sources.cfg in
buildout.coredev).

Post by David Glick (Plone)

Post by Nathan Van Gheem
Also, what does everything think about Archetypes and
plone.app.widgets. Should that code be merged as well or do we just start
ignoring Archetypes in plone 5 a bit?
I think if we ignore Archetypes in Plone 5, it will significantly

discourage users with custom AT content types from upgrading to Plone 5.

--
Nathan Van Gheem
Solutions Architect
Wildcard Corp

David Glick (Plone)

2015-01-26 06:03:24 UTC

Permalink

Yeah, maybe leave the base widgets in plone.app.widgets, and just move
the Dexerity- and Archetypes- specific code (e.g. widget subclasses) and
configuration to Plone 5-specific branches of plone.app.dexterity and
Products.Archetypes.

Post by Nathan Van Gheem
We could keep most of plone.app.widgets and just move all override
stuff into other packages(at_bbb.py, dx_bbb.py, skins). I'd then also
just cut a plone 4 only branch of plone.app.widgets.
Sound better?
ahh cool. I was just reading the docs and didn't notice any
specifics about that.
On Sun, Jan 25, 2015 at 11:42 PM, David Glick (Plone)

On Sun, Jan 25, 2015 at 11:33 PM, David Glick (Plone)
Hi All,
I'd like to merge plone.app.widgets into all of other
plone packages for plone 5.
In doing so, I need to create some plone 4 only
branches for plone.app.dexterity and
plone.app.contenttypes.
Any objections?
I don't really understand the benefit of spending effort
to move the code. Is there an important reason I'm
forgetting?
plone.app.widgets overrides things in other packages to work
so it's a bit of indirection. I'd like to cut off
plone.app.widgets and whoever wants to maintain it for plone
4 can if they care to.

Okay. I agree it would be ideal to avoid those overrides,
although it maybe should be considered lower priority than
fixing bugs in Plone 5.
It looks like we already have branches for these packages --
Plone 4.3 is using the 2.0.x branch of plone.app.dexterity and
the 1.1.x branch of plone.app.contenttypes (at least according
to sources.cfg in buildout.coredev).

Also, what does everything think about Archetypes and
plone.app.widgets. Should that code be merged as well
or do we just start ignoring Archetypes in plone 5 a bit?
I think if we ignore Archetypes in Plone 5, it will
significantly discourage users with custom AT content
types from upgrading to Plone 5.
Alright, we might need a branch for Archetypes also then :)

Also already exists -- Plone 4.3 uses the 1.9.x branch of
Products.Archetypes.
_______________________________________________
Framework-Team mailing list
https://lists.plone.org/mailman/listinfo/plone-framework-team
--
Nathan Van Gheem
Solutions Architect
Wildcard Corp
--
Nathan Van Gheem
Solutions Architect
Wildcard Corp

Ramon Navarro Bosch

2015-01-26 09:20:26 UTC

Permalink

Sounds great for me,

I would also remove the static folder, profiles and skins ( no need as its
not beeing used on plone 5) so the package is much smaller and easier to
maintain. There are two big zcml conditions depending if its plone 5 or not
and all resources don't need to be there anymore.

Ramon

El Mon Jan 26 2015 at 07:03:35, David Glick (Plone) (<***@plone.org>)
va escriure:

Yeah, maybe leave the base widgets in plone.app.widgets, and just move the

Post by David Glick (Plone)
Dexerity- and Archetypes- specific code (e.g. widget subclasses) and
configuration to Plone 5-specific branches of plone.app.dexterity and
Products.Archetypes.
We could keep most of plone.app.widgets and just move all override stuff
into other packages(at_bbb.py, dx_bbb.py, skins). I'd then also just cut a
plone 4 only branch of plone.app.widgets.
Sound better?

Post by Nathan Van Gheem
ahh cool. I was just reading the docs and didn't notice any specifics
about that.
On Sun, Jan 25, 2015 at 11:42 PM, David Glick (Plone) <

On Sun, Jan 25, 2015 at 11:33 PM, David Glick (Plone) <

Post by David Glick (Plone)

I don't really understand the benefit of spending effort to move the
code. Is there an important reason I'm forgetting?

plone.app.widgets overrides things in other packages to work so it's a
bit of indirection. I'd like to cut off plone.app.widgets and whoever wants
to maintain it for plone 4 can if they care to.
Okay. I agree it would be ideal to avoid those overrides, although it
maybe should be considered lower priority than fixing bugs in Plone 5.
It looks like we already have branches for these packages -- Plone 4.3
is using the 2.0.x branch of plone.app.dexterity and the 1.1.x branch of
plone.app.contenttypes (at least according to sources.cfg in
buildout.coredev).

Post by David Glick (Plone)

Post by Nathan Van Gheem
Also, what does everything think about Archetypes and
plone.app.widgets. Should that code be merged as well or do we just start
ignoring Archetypes in plone 5 a bit?
I think if we ignore Archetypes in Plone 5, it will significantly

discourage users with custom AT content types from upgrading to Plone 5.

--
Nathan Van Gheem
Solutions Architect
Wildcard Corp

--
Nathan Van Gheem
Solutions Architect
Wildcard Corp
_______________________________________________
Framework-Team mailing list
https://lists.plone.org/mailman/listinfo/plone-framework-team