Как вы версии ваших проектов?
Недостаток файла CSV без вложений означает, что ошибочная запятая в пользовательском вводе будет забивать строку. Поэтому вам нужно удалить запятые перед написанием строки CSV.
Сложная часть обработки CSV - это разбор приложений, что делает PHP и amp; Функции PEAR CSV ценны. По сути, вы ищете файл с разделителями-запятыми для столбцов и строки с разделителями строк для строк. Вот простая отправная точка:
<?php
$col_separator= ',';
$row_separator= "\n";
$a= array(
array('my', 'values', 'are', 'awes,breakit,ome'),
array('these', 'values', 'also', "rock\nAND\nROLL")
);
function encodeRow(array $a) {
global $col_separator;
global $row_separator;
// Can't have the separators in the column data!
$a2= array();
foreach ($a as $v) {
$a2[]= str_replace(array($col_separator, $row_separator), '', $v);
}
return implode($col_separator, $a2);
}
$output= array();
foreach ($a as $row) {
$output[]= encodeRow($row);
}
echo(implode($row_separator, $output));
?>
13 ответов
Мы обычно делаем major.minor [.maintenance [.build]], где я работаю, но это, кажется, варьируется немного на проект.
Главный/незначительный то же, поскольку Вы упомянули. обслуживание было бы увеличено для маленького (ошибка), фиксирует и сборка в течение каждого раза выполнения сервера сборки.
Посмотрите это: ТАК вопрос о номере версии
Мне лично нравится использовать схему, которая фокусируется на уровне назад совместимости, которую могут ожидать пользователи проекта/продукта:
Прежде 1.0:
- 0.0.1 = Первый выпуск
- , 0.-.X = Назад совместимое обновление
- 0. X.0 = Назад несовместимое обновление
После 1.0:
- -.-.X = Обновление без интерфейсных изменений
- -.X.0 = Обновление с назад совместимыми интерфейсными дополнениями
- X.0.0 = Назад несовместимое обновление
Используя совместимость как центральная точка в номере версии облегчает для пользователей, особенно если te продуктом является библиотека, чтобы судить, могут ли они ожидать smoothe и безопасный обновление или нет.
Я часто вижу Xyz, где X через год после номера выпуска и yz месяц года. Т.е. 201 2 января спустя годы после выпуска. Т.е. то, когда выпуски продукта в мае, это - первый номер выпуска, является 105. Выпуск в феврале в следующем году 202.
Я использую major.minor.point.revision, где точка является bugfix-единственным выпуском, и пересмотр является пересмотром репозитория. Это легко и работает хорошо.
Мы обычно присваиваем версию нашим проектам на основе текущей даты выпуска, YYYY.MM.DD.*, и мы позволяем номеру сборки генерировать автоматически, так например, если бы у нас был выпуск сегодня, то это было бы 26.09.2008. СБОРКА.
Major.minor.patch.build с патчем, являющимся текущими исправлениями или выпуском патча.
, Если Вы можете получить QA к в и находитесь на SVN, Вы могли бы использовать пересмотр ГОЛОВЫ svn в качестве номера сборки. Таким образом каждая сборка описывает, куда она прибыла из с точки зрения управления исходным кодом и что находится в сборке. Это действительно означает, что у Вас будут сборки, которые повышаются с разрывами (1.0.0.1, 1.0.0.34....)
Главный. Незначительный. BugFix. SVNRevision
, например: 3.5.2.31578
- Пересмотр SVN приносит Вам очень точный мир кода, отправленного клиенту. Вы абсолютно уверены, было ли это bugfix там или нет.
- Это также помогает нахождению надлежащего PDB в конечном счете, у Вас есть ошибка приложения. Просто соответствуйте Изменениям SVN на своем сервере сборки, скопируйте PDB в местоположение EXE, откройте отладчик, и Вы получили отслеживание стека катастрофического отказа.
Я просто делаю Major.minor. Так как я - единственный разработчик (со случайной справкой) работающий над веб-приложением, большинство людей не могло заботиться меньше о незначительных мерах, что я делаю. Таким образом, я просто выполняю итерации вспомогательных версий, когда я вставил новые возможности и номера основной версии, когда я делаю некоторую громадину изменения/обновления. Иначе я просто игнорирую маленькие меры, насколько номера версий идут (хотя у меня действительно есть числа пересмотра Подрывной деятельности, если я должен вернуться для меня).
Я работаю над большим количеством меньших проектов, и я лично нашел это полезным.
PatchNumber. DateMonthYear
, который Это для маленьких веб-инструментов, где пользователи видят, когда последнее обновление и как часто это было обновлено.
PatchNumber является количеством выпусков, которое было сделано, и остальное используется, чтобы показать пользователям, когда это было опубликовано.
У меня просто есть число. Первый выпуск 001. Третья бета второго выпуска 002b3 и так далее. Это только для персонального ума материала, мне ничего на самом деле 'не выпустили' в данный момент, таким образом, это - вся теория.
Я начал использовать псевдоаналогичный формат в качестве Ubuntu: Y.MMDD
Это помогает по нескольким причинам:
- легче проверить на требования версии: , если (версия < 8.0901) умирать/выходить/и т.д. ;
- это может быть автоматически сгенерировано в Вашем процессе сборки
На той 2-й точке (рубин & грабли):
def serial(t)
t = Time.now.utc if not t.instance_of?(Time)
t.strftime("%Y").to_i - 2000 + t.strftime("0.%m%d").to_f
end
serial(Time.now) #=> 8.0926
serial(Time.now.utc) #=> 8.0927
ПРИМЕЧАНИЕ: t.strftime (" %Y. % m%d"), .to_f - 2000 сталкивается с погрешностями с плавающей точкой: 8.09269999999992
Я раньше любил Нантакет способ управления версиями их компилятор Clipper в 80-х:
Зима 1984 года Clipper
Лето 1985 года Clipper
Зима 1985 года Clipper
Осень 1986 года Clipper
Лето 1987 года Clipper
, О, и оверлейные программы....
[становится слезным следивший]