[Xerte-dev] Re: New Build

[David Goodwin]

> I think we sort of need a roadmap though - because now we've got a
> deadline that is Nottingham's and it is defining everyone's work. But
> the majority of the work here isn't being done by Nottingham (and is
> for free). At some point a Nottingham person is going to have to start
> coding on this again, and it'll be a bit weird (because we've got
> different coders doing different things, that database queries are
> sort of PDO in some parts, and not PDO in other parts).
> 

The database queries all need moving over to use the db_query()/db_query_one() variants at some point in time. This will remove any chance of SQL Injection, remove the need for the programmer to sanitise variables (as long as they use the prepared statement syntax with ? place holders) and it should result in fewer lines of code. 

Finally, moving to use db_querY() everywhere means it would be very easy to support other database backends, if that ever becomes desirable.


> I get the feeling this is just a growing pain, but we could do with
> some thoughts on say
> 
> What will tag / branch 1.9 be?
> 

1.9 should be a branch - as you work in branches. Tags should be static and unchanging - so e.g. the 1.9.0 release would be a tag, but work would probably continue in the 1.9 branch as you fix bugs - eventually leading to a 1.9.1 release/tag.


> What sort of coding standards are there (the only thing really I would
> say is text strings for internationalisation are upper case - but some
> of the commits are indent changes

That's mostly me. My editor will reindent most stuff for me, and I find it easier to read if it's not consistent.


> - so are we going drupal like? I
> don't mind what we do - it just makes sense for people looking to
> commit changes they know it'll work. Once we got a commit for the PHP
> header change for the export code, but I never committed it because it
> broke Nottingham's export function. This isn't a big deal, but the
> idea of nightly build, or a test version before approval makes sense?

You're almost straying into Continuous Integration territory. For that to work you need unit tests in place, and your code base isn't really setup to support them.


> 
> If everyone uses bugfixes.txt as well that helps a lot, so all fixes
> are explained simply and listed for people to use. That way everyone
> can be on the most up to date version without worrying about anything.
> I know the SVN does it, as does the RSS feed - but it's not obvious or
> tied to the install in any place.
> 

bugfixes.txt?

I'd rather we had issues created on the google code tracker. You need to record changes/history around defects.

I do think we need a simple 'version.txt' file or similar in the document root; but that's a slightly different issue. Other projects will also have a 'changelog.txt' file- which is sort of linked to version.txt - and presumably details what's changed/been fixed/added between releases.

thanks,

David.


Pale Purple Ltd.  (Company No: 5580814)
'Business Web Application Development and Training in PHP'

http://www.palepurple.co.uk   
Office: 0845 0046746     Mobile: 07792380669 

Follow us on Twitter: @PalePurpleLtd