Features Extra official release

I'd like community input on this one from people who it use it for taxonomy and nodequeue more. I know the block import/export should be working pretty well now, but I'm not sure if it's in a state worthy of an official release quite yet.

The reason I'd like input is that I became a co-maintainer of this module recently and so I don't know it inside-out but do know there are various outstanding issues.

I think it would be helpful to define this module's approach in relation to the Features module.

The hallmark of 'Features' is that the features it creates can be swapped with any other site without overwriting configuration on another site.

FE deals with site elements that have numeric IDs in the database. Does this module intend to save those IDs in its features or not?

If it does then this module can be used for development teams to export configuration into code. Since we are saving IDs then things like Views can reliably be exported alongside nodequeues without them breaking.

If this module does not intend to maintain IDs then it is more oriented to site-builders who want to be able to add elements to their features that the Features module doesn't support.

As a developer on a team trying to export configuration to code I fall heavily on the side of the 'save IDS' approach. The commits I've made to fe_taxonomy have maintained vids and tids so that when one member of my team changes a taxonomy term that change cane easily be pushed to our dev or production sites via code.

Knowing how this module approaches that would be helpful in evaluating each of the components in this module and whether or not my contributions should be kept here or elsewhere.

I'd be interested in helping maintain this module if we are orienting this maintaining IDs.

@acouch: I don't know if it saves IDs at the moment. I believe it goes by machine-readable names that the user assigns, so to use it for existing blocks added via "add block," machine names must be assigned. I haven't played with the taxonomy/nodequeue parts much. However, the standard Features way is to use machine-readable names to export/import content. FE says in any case that it only has "faux-exportable" support for what it supports...so it won't be the exact same.

My concern is that storing iDs would break it for people who don't use it with your workflow. We could bridge the gap with a UI screen perhaps showing all custom blocks/vocabs/nodequeues in a list that don't have machine names and allowing you to enter them. It's a one-time thing, and then you get the full benefits of FE.

Bit of a ramble here, but what do you think? Did I understand what you were saying correctly?

I still need more info on what people think regarding this. I think this module's days are numbered as newer and better ways of doing things are developed.

I'm open to input regarding this.

7.x-1.0-alpha1 has been released today.