Maybe we should release 0.9.7 instead

Too late... now I’m up to version 3.0.2.

But in all seriousness, 0.9.5 with as many bugfixes as possible in the next 7-10 days (with a public beta hopefully this weekend).

Then I think we should focus our efforts on the new base system and manager efforts. And I suspect it could be released within 6 weeks of 0.9.5 (public beta within a couple of weeks?). A number somewhere between 0.9.6 and 0.9.9 makes sense for that... I don’t really have any preference there.

This blows my mind. so cool that this project does not sleep but runs like a oiled locomotive .
great work.

If there is need for a testing ground, I could set up a domain where the team hase full access to, to test on another server then you already use.

I am running the folloing config:
Plesk Reloaded 7.5 on RedHead Linux enterprice
apache 1.3.31
php 4.3.2-26.ent.1.swsoft
phpmyadmin 2.5.3
mysql 4.1.15 standard
php mysql cient api 3.23.58

let me know If this is somthing that the team can use to test.

I wil test myself also using the same server but maby not as deep as the coders do.

Quote from: rthrash at Sep 07, 2006, 11:46 PM

But in all seriousness, 0.9.5 with as many bugfixes as possible in the next 7-10 days (with a public beta hopefully this weekend). Then I think we should focus our efforts on the new base system and manager efforts. And I suspect it could be released within 6 weeks of 0.9.5 (public beta within a couple of weeks?). A number somewhere between 0.9.6 and 0.9.9 makes sense for that... I don’t really have any preference there.

This is a great plan. About version number : I think it would be consistent to pick a number according to how many release there will be before we release 1.0. I would be in favor of not jumping to 0.9.8 right now, as we don’t know when 1.0 will be available -> or do we ?).

In any case, I think we should definitely keep 1.0 as the keystone of severing all ties to the Etomite Legacy, and entering a whole new age for MODx entirely. I know it’s just rev numbers, but as far as communication and marketing goes, it will be far easier to emphasize the huge leap from 0.9.x to 1.0 than saying 1.2 is the great new release that will change it all. Last but not least, I believe in consistency : it’s way easier to say that 0.9.x release are Eto-Legacy release and 1.0 is a new rewritten app, a starting point for MODx.

Quote from: davidm at Sep 08, 2006, 02:56 AM

...as far as communication and marketing goes, it will be far easier to emphasize the huge leap from 0.9.x to 1.0 than saying 1.2 is the great new release that will change it all. Last but not least, I believe in consistency : it’s way easier to say that 0.9.x release are Eto-Legacy release and 1.0 is a new rewritten app, a starting point for MODx.

Agree. But:

I think it would be consistent to pick a number according to how many release there will be before we release 1.0. I would be in favor of not jumping to 0.9.8 right now, as we don’t know when 1.0 will be available -> or do we ?).

Another way to look at that is to pick a number that allows for the amount of *major* work that will happen between 0.9.next-but-one and 1.0. It strikes me that after the big bang of introducing xPDO, the releases will be much more incremental until the full rewrite of 1.0 and predominantly just bugfix releases - thus we could get away with "0.9.8.4", "0.9.8.5" etc.

Besides, we can always go hex and release 0.A!

Some key points on the long-term plan of getting to 1.0 from my perspective:

STEP 1: Release 0.9.7 with new xPDO core and complete legacy support (at least 95+%); start making the new familiar without taking away what already is
STEP 2: Start transitioning all core MODx code to use the xPDO-based API’s; this includes a new Manager hopefully
STEP 3: Complete xPDO Transport services (i.e. move data anywhere) and related Data-Migration tool to support imports, exports, and mapping data fields across differing data models; this will allow xPDO to auto-detect schema changes and auto-upgrade data structures based on access to different versions of an xPDO object with a properly defined migration map, similar to an RoR feature
STEP 4: Prepare a new package installation service that uses the xPDO transport and data migration features to allow the core and/or add-ons to be distributed with ease
STEP 5: Map out and document the required efforts to migrate to the 1.0 data model, which will allow the more advanced features, like versioning, internationalization, etc. to come to fruition
STEP 6: Release 1.0 (sounds easy enough, eh?)

As Paul suggests, between step 1 and 6, we should leave plenty of room for additional releases, as rolling out new features and bug fixes I believe will be much easier to achieve with this new architecture; i.e. I expect it to see an increase in the frequency of both.

I didn’t mention a lot of features in this plan, because I really think the progress and efforts into Steps 3 and 4 might be the key to success here. Making it easy to share and migrate any kind of MODx data from one place to another will allow all MODx developers and designers to be more productive, by keeping them focused on what they do best, and ultimately by making it easier for contributions to evolve quickly within the community. And most importantly, it makes the transition that much easier for us to deal with, by providing an important tool to manage the technical upgrade efforts in an organized way.