Правильный способ создания релизов в Launchpad?

Я думаю, что Launchpad использует эти слова, поскольку они более «родовые» - они могут использоваться для различных стилей разработки, не заставляя проект управлять исходным кодом, разрабатывать и выпускать определенным образом.

Я вижу главным образом два способа разработки проекта на Launchpad:

Позже проще. Первый более удобный, когда вам нужно предоставить исправления ошибок при работе над большими изменениями для более поздней версии (более необходимо, если это не сольный проект).

HTH

Я думаю, что Launchpad использует эти слова, поскольку они более «родовые» - они могут использоваться для различных стилей разработки, не заставляя проект управлять исходным кодом, разрабатывать и выпускать определенным образом.

Я вижу главным образом два способа разработки проекта на Launchpad:

Позже проще. Первый более удобный, когда вам нужно предоставить исправления ошибок при работе над большими изменениями для более поздней версии (более необходимо, если это не сольный проект).

HTH

Я думаю, что Launchpad использует эти слова, поскольку они более «родовые» - они могут использоваться для различных стилей разработки, не заставляя проект управлять исходным кодом, разрабатывать и выпускать определенным образом.

Я вижу главным образом два способа разработки проекта на Launchpad:

Позже проще. Первый более удобный, когда вам нужно предоставить исправления ошибок при работе над большими изменениями для более поздней версии (более необходимо, если это не сольный проект).

HTH

Я думаю, что Launchpad использует эти слова, поскольку они более «родовые» - они могут использоваться для разных стилей разработки, не заставляя проект управлять исходным кодом, разрабатывать и выпускать определенным образом.

Я вижу, главным образом, два способа разработки проекта на Launchpad:

1. Разработка вашего проекта нелинейна (не уверен, что это правильное слово). Это, как правило, верно, если для вас важно поддерживать более чем одну версию за раз, развиваясь в нестабильной / ветви развития. (Думайте, что параллельно разрабатывайте две версии) Например, GNOME имеет версии xyz с нечетным y , подразумевающим ряд разработки и даже y , предполагающий устойчивый ряд , GNOME выпускает 2.30 как стабильный для мира. После выпуска разработчики начинают работать над 2.31.x , который нестабилен. Если они найдут какую-либо важную ошибку, которую они хотели бы исправлять для пользователей, работающих под управлением 2.30 , не предоставляя огромное количество неполированных новых функций, они исправляют только эту ошибку в 2.30 и освобождают 2.30.1 . Если вы знакомы с bzr , вы должны понимать это с точки зрения 2.31 , который разрабатывается на магистрали, тогда как 2.30 является ветвью trunk (разветвленный, когда 2.29 стал стабильным и был выпущен как 2.30 ), где сделаны только исправления ошибок. В этом случае вы должны сделать одну серию для каждого 2.29 , 2.30 , 2.31 и т. Д. И одной строки , 2.29 и 2.30 будут разделять одну и ту же ветвь bzr (поскольку 2.30 - 2.29 после он полируется). 2.31 и trunk будут использовать одну и ту же ветвь bzr . Когда вы отпустите 2.32 , затем перейдете в эту ветвь и вызовите эту ветвь 2.32 (это будет ветвь bzr для обоих 2.31 и 2.32 ). Примером вехи в этом случае является 2.30.2 (в серии 2.30 ). Веха отличается от выпуска тем, что вехой является будущий выпуск, и как только эта версия будет выпущена, эта веха станет выпуском. Вот почему имеет смысл ориентировать ошибку на веху (будущее), и вы можете сделать ошибку, которая влияет только (скажем) на две из пяти серий, потому что она затрагивает только две из них и должна быть зафиксирована на их соответствующих ветвях (вероятно, текущий стабильный релиз и багажник)
2. Разработка вашего проекта linear . Это означает, что вы выпустите версию 1.1 для всех пользователей, продолжайте разрабатывать функции и исправлять ошибки до тех пор, пока не будете готовы к 1.2 или 2.0 (или как хочешь). Затем вы выпускаете последний доступный код. В этом случае вы не разрабатываете разные версии параллельно, как показано на диаграмме серии Launchpad). В этом случае у вас есть только одна серия, одна ветвь базара (предположительно) trunk предположительно), и все ваши этапы и выпуски находятся в этой одной серии ( 0,1 , 1.0 , 1.1 или 2.0 )

Позже проще. Первый более подходящий, когда вам нужно предоставить исправления ошибок, когда вы работаете над большими изменениями для более поздней версии (более необходимо, если это не сольный проект).

HTH

Я думаю, что Launchpad использует эти слова, поскольку они более «родовые» - они могут использоваться для разных стилей разработки, не заставляя проект управлять исходным кодом, разрабатывать и выпускать определенным образом.

Я вижу, главным образом, два способа разработки проекта на Launchpad:

1. Разработка вашего проекта нелинейна (не уверен, что это правильное слово). Это, как правило, верно, если для вас важно поддерживать более чем одну версию за раз, развиваясь в нестабильной / ветви развития. (Думайте, что параллельно разрабатывайте две версии) Например, GNOME имеет версии xyz с нечетным y , подразумевающим ряд разработки и даже y , предполагающий устойчивый ряд , GNOME выпускает 2.30 как стабильный для мира. После выпуска разработчики начинают работать над 2.31.x , который нестабилен. Если они найдут какую-либо важную ошибку, которую они хотели бы исправлять для пользователей, работающих под управлением 2.30 , не предоставляя огромное количество неполированных новых функций, они исправляют только эту ошибку в 2.30 и освобождают 2.30.1 . Если вы знакомы с bzr , вы должны понимать это с точки зрения 2.31 , который разрабатывается на магистрали, тогда как 2.30 является ветвью trunk (разветвленный, когда 2.29 стал стабильным и был выпущен как 2.30 ), где сделаны только исправления ошибок. В этом случае вы должны сделать одну серию для каждого 2.29 , 2.30 , 2.31 и т. Д. И одной строки , 2.29 и 2.30 будут разделять одну и ту же ветвь bzr (поскольку 2.30 - 2.29 после он полируется). 2.31 и trunk будут использовать одну и ту же ветвь bzr . Когда вы отпустите 2.32 , затем перейдете в эту ветвь и вызовите эту ветвь 2.32 (это будет ветвь bzr для обоих 2.31 и 2.32 ). Примером вехи в этом случае является 2.30.2 (в серии 2.30 ). Веха отличается от выпуска тем, что вехой является будущий выпуск, и как только эта версия будет выпущена, эта веха станет выпуском. Вот почему имеет смысл ориентировать ошибку на веху (будущее), и вы можете сделать ошибку, которая влияет только (скажем) на две из пяти серий, потому что она затрагивает только две из них и должна быть зафиксирована на их соответствующих ветвях (вероятно, текущий стабильный релиз и багажник)
2. Разработка вашего проекта linear . Это означает, что вы выпустите версию 1.1 для всех пользователей, продолжайте разрабатывать функции и исправлять ошибки до тех пор, пока не будете готовы к 1.2 или 2.0 (или как хочешь). Затем вы выпускаете последний доступный код. В этом случае вы не разрабатываете разные версии параллельно, как показано на диаграмме серии Launchpad). В этом случае у вас есть только одна серия, одна ветвь базара (предположительно) trunk предположительно), и все ваши этапы и выпуски находятся в этой одной серии ( 0,1 , 1.0 , 1.1 или 2.0 )

Позже проще. Первый более подходящий, когда вам нужно предоставить исправления ошибок, когда вы работаете над большими изменениями для более поздней версии (более необходимо, если это не сольный проект).

HTH

Я думаю, что Launchpad использует эти слова, поскольку они более «родовые» - они могут использоваться для разных стилей разработки, не заставляя проект управлять исходным кодом, разрабатывать и выпускать определенным образом.

Я вижу, главным образом, два способа разработки проекта на Launchpad:

1. Разработка вашего проекта нелинейна (не уверен, что это правильное слово). Это, как правило, верно, если для вас важно поддерживать более чем одну версию за раз, развиваясь в нестабильной / ветви развития. (Думайте, что параллельно разрабатывайте две версии) Например, GNOME имеет версии xyz с нечетным y , подразумевающим ряд разработки и даже y , предполагающий устойчивый ряд , GNOME выпускает 2.30 как стабильный для мира. После выпуска разработчики начинают работать над 2.31.x , который нестабилен. Если они найдут какую-либо важную ошибку, которую они хотели бы исправлять для пользователей, работающих под управлением 2.30 , не предоставляя огромное количество неполированных новых функций, они исправляют только эту ошибку в 2.30 и освобождают 2.30.1 . Если вы знакомы с bzr , вы должны понимать это с точки зрения 2.31 , который разрабатывается на магистрали, тогда как 2.30 является ветвью trunk (разветвленный, когда 2.29 стал стабильным и был выпущен как 2.30 ), где сделаны только исправления ошибок. В этом случае вы должны сделать одну серию для каждого 2.29 , 2.30 , 2.31 и т. Д. И одной строки , 2.29 и 2.30 будут разделять одну и ту же ветвь bzr (поскольку 2.30 - 2.29 после он полируется). 2.31 и trunk будут использовать одну и ту же ветвь bzr . Когда вы отпустите 2.32 , затем перейдете в эту ветвь и вызовите эту ветвь 2.32 (это будет ветвь bzr для обоих 2.31 и 2.32 ). Примером вехи в этом случае является 2.30.2 (в серии 2.30 ). Веха отличается от выпуска тем, что вехой является будущий выпуск, и как только эта версия будет выпущена, эта веха станет выпуском. Вот почему имеет смысл ориентировать ошибку на веху (будущее), и вы можете сделать ошибку, которая влияет только (скажем) на две из пяти серий, потому что она затрагивает только две из них и должна быть зафиксирована на их соответствующих ветвях (вероятно, текущий стабильный релиз и багажник)
2. Разработка вашего проекта linear . Это означает, что вы выпустите версию 1.1 для всех пользователей, продолжайте разрабатывать функции и исправлять ошибки до тех пор, пока не будете готовы к 1.2 или 2.0 (или как хочешь). Затем вы выпускаете последний доступный код. В этом случае вы не разрабатываете разные версии параллельно, как показано на диаграмме серии Launchpad). В этом случае у вас есть только одна серия, одна ветвь базара (предположительно) trunk предположительно), и все ваши этапы и выпуски находятся в этой одной серии ( 0,1 , 1.0 , 1.1 или 2.0 )

Позже проще. Первый более подходящий, когда вам нужно предоставить исправления ошибок, когда вы работаете над большими изменениями для более поздней версии (более необходимо, если это не сольный проект).

HTH

Я думаю, что Launchpad использует эти слова, поскольку они более «родовые» - они могут использоваться для разных стилей разработки, не заставляя проект управлять исходным кодом, разрабатывать и выпускать определенным образом.

Я вижу, главным образом, два способа разработки проекта на Launchpad:

1. Разработка вашего проекта нелинейна (не уверен, что это правильное слово). Это, как правило, верно, если для вас важно поддерживать более чем одну версию за раз, развиваясь в нестабильной / ветви развития. (Думайте, что параллельно разрабатывайте две версии) Например, GNOME имеет версии xyz с нечетным y , подразумевающим ряд разработки и даже y , предполагающий устойчивый ряд , GNOME выпускает 2.30 как стабильный для мира. После выпуска разработчики начинают работать над 2.31.x , который нестабилен. Если они найдут какую-либо важную ошибку, которую они хотели бы исправлять для пользователей, работающих под управлением 2.30 , не предоставляя огромное количество неполированных новых функций, они исправляют только эту ошибку в 2.30 и освобождают 2.30.1 . Если вы знакомы с bzr , вы должны понимать это с точки зрения 2.31 , который разрабатывается на магистрали, тогда как 2.30 является ветвью trunk (разветвленный, когда 2.29 стал стабильным и был выпущен как 2.30 ), где сделаны только исправления ошибок. В этом случае вы должны сделать одну серию для каждого 2.29 , 2.30 , 2.31 и т. Д. И одной строки , 2.29 и 2.30 будут разделять одну и ту же ветвь bzr (поскольку 2.30 - 2.29 после он полируется). 2.31 и trunk будут использовать одну и ту же ветвь bzr . Когда вы отпустите 2.32 , затем перейдете в эту ветвь и вызовите эту ветвь 2.32 (это будет ветвь bzr для обоих 2.31 и 2.32 ). Примером вехи в этом случае является 2.30.2 (в серии 2.30 ). Веха отличается от выпуска тем, что вехой является будущий выпуск, и как только эта версия будет выпущена, эта веха станет выпуском. Вот почему имеет смысл ориентировать ошибку на веху (будущее), и вы можете сделать ошибку, которая влияет только (скажем) на две из пяти серий, потому что она затрагивает только две из них и должна быть зафиксирована на их соответствующих ветвях (вероятно, текущий стабильный релиз и багажник)
2. Разработка вашего проекта linear . Это означает, что вы выпустите версию 1.1 для всех пользователей, продолжайте разрабатывать функции и исправлять ошибки до тех пор, пока не будете готовы к 1.2 или 2.0 (или как хочешь). Затем вы выпускаете последний доступный код. В этом случае вы не разрабатываете разные версии параллельно, как показано на диаграмме серии Launchpad). В этом случае у вас есть только одна серия, одна ветвь базара (предположительно) trunk предположительно), и все ваши этапы и выпуски находятся в этой одной серии ( 0,1 , 1.0 , 1.1 или 2.0 )

Позже проще. Первый более подходящий, когда вам нужно предоставить исправления ошибок, когда вы работаете над большими изменениями для более поздней версии (более необходимо, если это не сольный проект).

HTH

Я думаю, что Launchpad использует эти слова, поскольку они более «родовые» - они могут использоваться для разных стилей разработки, не заставляя проект управлять исходным кодом, разрабатывать и выпускать определенным образом.

Я вижу, главным образом, два способа разработки проекта на Launchpad:

1. Разработка вашего проекта нелинейна (не уверен, что это правильное слово). Это, как правило, верно, если для вас важно поддерживать более чем одну версию за раз, развиваясь в нестабильной / ветви развития. (Думайте, что параллельно разрабатывайте две версии) Например, GNOME имеет версии xyz с нечетным y , подразумевающим ряд разработки и даже y , предполагающий устойчивый ряд , GNOME выпускает 2.30 как стабильный для мира. После выпуска разработчики начинают работать над 2.31.x , который нестабилен. Если они найдут какую-либо важную ошибку, которую они хотели бы исправлять для пользователей, работающих под управлением 2.30 , не предоставляя огромное количество неполированных новых функций, они исправляют только эту ошибку в 2.30 и освобождают 2.30.1 . Если вы знакомы с bzr , вы должны понимать это с точки зрения 2.31 , который разрабатывается на магистрали, тогда как 2.30 является ветвью trunk (разветвленный, когда 2.29 стал стабильным и был выпущен как 2.30 ), где сделаны только исправления ошибок. В этом случае вы должны сделать одну серию для каждого 2.29 , 2.30 , 2.31 и т. Д. И одной строки , 2.29 и 2.30 будут разделять одну и ту же ветвь bzr (поскольку 2.30 - 2.29 после он полируется). 2.31 и trunk будут использовать одну и ту же ветвь bzr . Когда вы отпустите 2.32 , затем перейдете в эту ветвь и вызовите эту ветвь 2.32 (это будет ветвь bzr для обоих 2.31 и 2.32 ). Примером вехи в этом случае является 2.30.2 (в серии 2.30 ). Веха отличается от выпуска тем, что вехой является будущий выпуск, и как только эта версия будет выпущена, эта веха станет выпуском. Вот почему имеет смысл ориентировать ошибку на веху (будущее), и вы можете сделать ошибку, которая влияет только (скажем) на две из пяти серий, потому что она затрагивает только две из них и должна быть зафиксирована на их соответствующих ветвях (вероятно, текущий стабильный релиз и багажник)
2. Разработка вашего проекта linear . Это означает, что вы выпустите версию 1.1 для всех пользователей, продолжайте разрабатывать функции и исправлять ошибки до тех пор, пока не будете готовы к 1.2 или 2.0 (или как хочешь). Затем вы выпускаете последний доступный код. В этом случае вы не разрабатываете разные версии параллельно, как показано на диаграмме серии Launchpad). В этом случае у вас есть только одна серия, одна ветвь базара (предположительно) trunk предположительно), и все ваши этапы и выпуски находятся в этой одной серии ( 0,1 , 1.0 , 1.1 или 2.0 )

Позже проще. Первый более подходящий, когда вам нужно предоставить исправления ошибок, когда вы работаете над большими изменениями для более поздней версии (более необходимо, если это не сольный проект).

HTH

Я думаю, что Launchpad использует эти слова, поскольку они более «родовые» - они могут использоваться для разных стилей разработки, не заставляя проект управлять исходным кодом, разрабатывать и выпускать определенным образом.

Я вижу, главным образом, два способа разработки проекта на Launchpad:

1. Разработка вашего проекта нелинейна (не уверен, что это правильное слово). Это, как правило, верно, если для вас важно поддерживать более чем одну версию за раз, развиваясь в нестабильной / ветви развития. (Думайте, что параллельно разрабатывайте две версии) Например, GNOME имеет версии xyz с нечетным y , подразумевающим ряд разработки и даже y , предполагающий устойчивый ряд , GNOME выпускает 2.30 как стабильный для мира. После выпуска разработчики начинают работать над 2.31.x , который нестабилен. Если они найдут какую-либо важную ошибку, которую они хотели бы исправлять для пользователей, работающих под управлением 2.30 , не предоставляя огромное количество неполированных новых функций, они исправляют только эту ошибку в 2.30 и освобождают 2.30.1 . Если вы знакомы с bzr , вы должны понимать это с точки зрения 2.31 , который разрабатывается на магистрали, тогда как 2.30 является ветвью trunk (разветвленный, когда 2.29 стал стабильным и был выпущен как 2.30 ), где сделаны только исправления ошибок. В этом случае вы должны сделать одну серию для каждого 2.29 , 2.30 , 2.31 и т. Д. И одной строки , 2.29 и 2.30 будут разделять одну и ту же ветвь bzr (поскольку 2.30 - 2.29 после он полируется). 2.31 и trunk будут использовать одну и ту же ветвь bzr . Когда вы отпустите 2.32 , затем перейдете в эту ветвь и вызовите эту ветвь 2.32 (это будет ветвь bzr для обоих 2.31 и 2.32 ). Примером вехи в этом случае является 2.30.2 (в серии 2.30 ). Веха отличается от выпуска тем, что вехой является будущий выпуск, и как только эта версия будет выпущена, эта веха станет выпуском. Вот почему имеет смысл ориентировать ошибку на веху (будущее), и вы можете сделать ошибку, которая влияет только (скажем) на две из пяти серий, потому что она затрагивает только две из них и должна быть зафиксирована на их соответствующих ветвях (вероятно, текущий стабильный релиз и багажник)
2. Разработка вашего проекта linear . Это означает, что вы выпустите версию 1.1 для всех пользователей, продолжайте разрабатывать функции и исправлять ошибки до тех пор, пока не будете готовы к 1.2 или 2.0 (или как хочешь). Затем вы выпускаете последний доступный код. В этом случае вы не разрабатываете разные версии параллельно, как показано на диаграмме серии Launchpad). В этом случае у вас есть только одна серия, одна ветвь базара (предположительно) trunk предположительно), и все ваши этапы и выпуски находятся в этой одной серии ( 0,1 , 1.0 , 1.1 или 2.0 )

Позже проще. Первый более подходящий, когда вам нужно предоставить исправления ошибок, когда вы работаете над большими изменениями для более поздней версии (более необходимо, если это не сольный проект).

HTH