[Xerte-dev] Re: New Build

[Pat Lockley]

But if it's only a list of the files replaced between versions then
someone wanting to know which files to swap can do it really easily.

On Thu, Mar 8, 2012 at 9:09 AM, Julian Tenney
<Julian.Tenney at nottingham.ac.uk> wrote:
> I'd rather we had issues created on the google code tracker. You need to record changes/history around defects.
>
> Same here. The list of bug fixes is too long to of use to most people, and you can examine the issues tracked on google code after they've been closed if there is a particular issue you really care about.
>
> We do need to include a clear statement of the version somewhere, so I just updated version.txt ;-)
>
> -----Original Message-----
> From: xerte-dev-bounces at lists.nottingham.ac.uk [mailto:xerte-dev-bounces at lists.nottingham.ac.uk] On Behalf Of David Goodwin
> Sent: 07 March 2012 21:51
> To: For Xerte technical developers
> Subject: [Xerte-dev] Re: New Build
>
>
>> 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
>
>
>
>
>
>
> _______________________________________________
> Xerte-dev mailing list
> Xerte-dev at lists.nottingham.ac.uk
> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev
>
> _______________________________________________
> Xerte-dev mailing list
> Xerte-dev at lists.nottingham.ac.uk
> http://lists.nottingham.ac.uk/mailman/listinfo/xerte-dev
>
> This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.   Please do not use, copy or disclose the information contained in this message or in any attachment.  Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.
>
> This message has been checked for viruses but the contents of an attachment
> may still contain software viruses which could damage your computer system:
> you are advised to perform your own checks. Email communications with the
> University of Nottingham may be monitored as permitted by UK legislation.
>