Add-on workflow question

Quote from: BobRay at Sep 25, 2008, 11:57 AM

Is there a similar add-on repository I could use for Evo versions?

No, you are welcome to maintain Evolution-specific versions in there too, just wasn’t what I intended (I intended for legacy development to stop, but...). Just make sure you give your Evo and Revo specific branches different version numbers and a branch can absolutely represent an Evo release, but none of the build stuff would apply obviously.

Quote from: BobRay at Sep 25, 2008, 11:48 AM

Um ... because if it’s a component, the core doesn’t know it exists until you install it?

Ah, okay, I didn’t follow at first.

The way I get around that - say I’m creating a Snippet - I create the object manually in MODx, but have it straight-up include the MODx Comp file first.

A snippet in my environment would look something like this:


I then can delete that test snippet when i’m done developing.

The downside to my approach is that you’ll have to manually create the DB data while developing, and then remove it when you’re ready to test building/installing.

There’s trade-offs, either way.

Quote from: OpenGeek at Sep 25, 2008, 12:42 PM

Quote from: BobRay at Sep 25, 2008, 11:57 AM

Is there a similar add-on repository I could use for Evo versions?

No, you are welcome to maintain Evolution-specific versions in there too, just wasn’t what I intended (I intended for legacy development to stop, but...). Just make sure you give your Evo and Revo specific branches different version numbers and a branch can absolutely represent an Evo release, but none of the build stuff would apply obviously.

Any reason not to have separate directory for the Evo release rather than a branch? That would make me (and maybe others) less likely to confuse the two.

Quote from: BobRay at Sep 25, 2008, 06:53 PM

Any reason not to have separate directory for the Evo release rather than a branch? That would make me (and maybe others) less likely to confuse the two.

Well, I would ask, are we going to do the same for each major version of the platform we release? I’d rather not see ditto_evo ditto_revo and ditto_nextcodenamehere as top level projects. Each reference project that we accept to be incubated in the modx-components repository should have a single, consistent identity, or IMO, it should get a new name altogether.

I’d also be more inclined as a developer to want all the versions in the same project structure to ease sharing changes (i.e. merging/switching) between the various branches intended for different target platforms, so ditto/branches/2.0 is the Evo compatible version and ditto/branches/3.0 is the Revo compatible one. Ditto is a single project, and features and parts of the implementation will be common across the versions, and to me, putting the versions under different projects would be confusing in that sense.

As for trunk/, that should be the latest stable version for the latest stable platform, but this is the biggest problem area when trying to maintain simultaneous stable releases as we are doing.

Finally, I fear the additional separation might tend to discourage folks from adopting Revolution, thinking the chasm is too wide to cross, and the whole idea of the single MODx brand with Evo and Revo codenames is to reduce that problem without denying the challenges. Similarly, the download repository, where releases are presented for download manually or via the WTF service will also make more sense if we keep all Ditto releases under the same entry. Filtering/searching by compatible MODx version will be the solution there.

Anyway, those are my thoughts on it. These are challenges that need consensus, so let’s explore this from all perspectives we can before we decide on how to define this "best practice".

All good points. My fear (beside the possible confusion of branches for me) was that newcomers to MODX (of which there could be thousands at some point) won’t all be careful or competent and will inevitably be installing components in releases where they won’t work. This will certainly happen anyway given the differences between Evo and Revo ways of doing things and we could spend a lot of time helping frustrated users sort this out.

Anything we can do to minimize that might be worth some sacrifices. Most of those users aren’t likely to see the code repository so it’s not a huge issue there, but the idea of just having version numbers 2.x and 3.x seems inadequate to head them off, IMO. I wonder if we shouldn’t start thinking about a version prefix like Ditto-Evo-3.x or at least Ditto-E3.x, if not a separate repository

I can definitely see the advantage of having them in the same repo directory, especially something like Ditto where many of the pieces will be shared. For some elements (plugins in particular), though, there could be pretty deep differences between the versions.

The notion that we don’t want to call attention to the gap between Evo and Revo makes some sense, but having worked with both, I honestly don’t think I’d recommend Evo to anyone once we’re past Beta. The package installation tool alone is enough to make me lean that way. The lexicon tools, searchable System Settings, contexts, etc. are just frosting on the cake. I think originally, the big deal about Revo was supposed to be contexts (and there’s no question that that’s a tremendous feature for power developers). I suspect, though, that over 90% of users will never consider using contexts but will go nuts for Revo’s vastly improved tools and user interface. I’ll predict that within a year or two of the Revo official release, Evo will be like Etomite is now.

Having worked in both on a day-to-day basis, I can’t wait to start converting real-world sites to Revolution. And, on that topic, I hope there’ll soon be an alpha that’s secure enough that people can start testing it on a wide variety of remote hosts.

Anyone reading the above discussions about packaging and building packages should keep in mind this is clearly for developers. You could still make manually installed snippets and add-ons just like you do now in modx. For developers though that need to package up suites of add-ons, content, etc., the packaging services are really a huge boon. (The stuff above could make Revo seem WAY more scary than it is in actual use.)

Is there any reason we can’t have Revo resources only provided via the packaging transport mechanisms and Evo only installable via the traditional download/copy-paste/FTP to your install methods? Add a couple of icons to denote which ones work in which versions ... would that make it more clear? My gut check says changing the name is a compromise which may have a better solution, though that would certainly work as well.