I really think Craig should release the current codebase, less the Attachment patch, as the Beta 2 now. I have been doing a lot with it except for some WikiTalk programming that I wat to try and it is rock solid for me.
I would push to put the Attachment patch in a feature branch, except for two reservations. First, I do not fully understand the additional load on the admin for publishing a main and branch release. Second, is the original codebase that does not meet current programming standards. Is subversion better at managing signifact re-ordering of code than WinMerge? If it is then there is really no problem, otherwise code refactoring should occur in the trunk before any changes are made in a branch. I am unsure what interface Pascal is thinking of implementing for the upload and attachment properties, but I am sure it will be easier for him if he didn't have to deal with the interface in the pending Attachment patch (even though the code is inactive in default state, it is still part of the page, though in a hidden state). Perhaps Pascal would also be willing to have a feature branch? Craig failed to mention that the attachment patch currently has no test code. I must emphasize that htis is a quick hack and the fact that it would only exist in the core code for a short period of time anyway, is another argument for putting it in a branch rather than the trunk. It would also make it easier to respond to the attachment user community (if there is one) without impacting the main community adversely. John Davidson On 7/20/07, Craig Andera <[EMAIL PROTECTED]> wrote: > > I encourage you to continue work. What I am doing is really just a > > simple hack to provide some bare functionality with minimal > > integration, only at the Web App level. > > OK, so I'd love to hear what other people think on this front, but here's my > non-authoritative take: > > I think we should put in John's support for attachments as a default-to-off > feature of FlexWiki 2.0. It should be heavily commented in FlexWiki 2.0 to > point out the drawbacks - the non-support for namespaces, the fact that it's > outside normal FlexWiki security policy, the fact that it's tied to the > filesystem, etc. People can flip it on if they really need attachment > support, but we aren't going to guarantee backwards-compatibility. > > I think Pascal's code should go into a future (post 2.0 RTW) version of > FlexWiki. Whether that's 2.2 or 3.0 or what, I have no idea: at this point > I've got so much 2.0 fatigue that I can't see that far. I will say that I'd > hope it would make an appearance around the same time as the configurable > parser, since they both affect the core in potentially significant ways. We > can easily branch the 2.0 [1] code any time we want to make this happen. At > this point it would probably make sense to make the 2.2/3.0 branch the head > and march towards completion on the 2.0 branch. [2] > > I'm going to sit on John's patch until next week. I'd really like to hear > comment from the community - John and Pascal in particular, but everyone > who's interested in this feature, really. Assuming that my proposal is the > way forward, I'll integrate John's change in a default-to-off configuration. > I'd like to call that Beta 2 - I feel like I've fixed all the important bugs > in the post-Beta 1 code, and it'd be nice to get a Beta 2 out there for > people to play with. > > Thoughts? > > [1] Oddly, many people seem to fear branches. Don't: they're a good thing! > :) > [2] Oddly, many people seem to fear merging. Don't: it's a good thing! :) > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Flexwiki-users mailing list > Flexwiki-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flexwiki-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
