What follows are a series of posts looking at the porting process. I am going to kick off with methodology and considerations.
Methodology
At this stage I am working on a proof of concept. The idea is to get Umbraco 4.7.2 up and running on Linux in the quickest possible way with the fewest possible changes. The methodology combines Agile techniques with signal extraction techniques - where the released stable Umbraco 4.7.2 source constitutes the signal. I am doing multiple passes (iterations) over the same signal - as it were to tune into the Linux channel. We can say that the Umbraco signal is arriving to the Linux channel in a degraded manner resulting in incomplete reconstitution. Our goal is to create a clean signal that will give us the clean "HD" CMS experience.
As with all signal extraction problems the GIGO, Garbage In - Garbage Out, principle applies. The rationale for choosing 4.7.2 is its high stable quality.
Here are the basic customer stories with the present status (the customer(s) being developer(s).
- Get 4.7.2 compiling on mono. Status: yes with mono 2.11.2, .NET 4.
- Get the application started and loaded without any 404 Resource XYZ not found errors. Minor code changes. Status: partially completed.
- Verify all UI functions. SQL errors, and further 404 Resource errors. Status: in progress.
- Get Unit tests working. Requires serious code changes. Status: partially completed.
Considerations
An important consideration is whether when the application becomes multi-platform, will the code for the other platforms be compiled and tested on each target platform? Or whether the code will be compiled and tested only on the source platform? I would recommend that the application is always compiled and tested on each target platform. Msunit, Pex & Moles do not work with mono, and unit tests would have to be ported and run on the target platform.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.