From: Andrey Orlov <cray@neural.ru> To: devel@altlinux.ru Subject: Re: [devel] Re: [sisyphus] Питоньи модуля Date: Sun, 11 Jan 2004 13:45:20 +0300 Message-ID: <200401111345.20731.cray@neural.ru> (raw) In-Reply-To: <20040111032820.GG12307@localhost.localdomain> On Sunday 11 January 2004 06:28, Alexey Morozov wrote: > Грустно. Почему - ниже. > > Старые версии питона, типа python22 остаются > > исключительно для целей разработки и тестирования, соответственно, > > предполагается что те, кому они нужны - в состоянии пересобрать все > Не понятно, зачем тогда держать такой пакет, если пользоваться им все равно > нельзя. Я уже объяснил. Для разработчиков. Сплит на две альтернативы произошел до моего появления в AltLinuxTeam и я точно не знаю чем он был вызван. Предположительно - тем, что Zope не работал с python22. С моим появлением ситуацию с Zope мы разрулили и по большому счету pythob21 стал не нужен. Но, как у мантейнера Zope, у меня иной раз возникала в нем необходимость. Просто чбы убедится в том, что некая бага не привнесена переносом Zope на python22, а воспроизводится на python21. С официальным переходом Zope на python223 пакет python21 стал не нужен. Сейчас ситуация повторяется с python22 / 23. > Тогда логичнее было бы делать так: > > python-<the last and shining version> > python-compat<any previous version> Оно сделано так как сделано. Считайте, что это осталоь так по историческим причинам. > > так и пишут "required". Таким образом, пересобрать новую версию пакета > > под оба питона сразу - в общем случе, нереально. > > %define _with_python<bad version> --without-python<bad version> > прямо в спеке? Тогда вы получите тоже самое что сейчас, только с другой стороны - у вас отвалятся MySQLdb, psycopg etc. Таким образом, вы опять не будете иметь полного набора пакетов для обеих версий питона. Я все это уже видел на 21 vs 22. Вы все-таки киньте мне на мыло посмотреть ваши макросы и т.п. Если бы я был 100% уверен в том, что это невозможно и ненужно - я бы даже обсуждать это не стал ;). > То есть, Вы утверждаете, что обратная совместимость есть всегда, и > ситуация, когда я при апгрейде питона и всех модулей получаю > неработоспособное приложения, невозможна, или, во всяком случае, _крайне_ > мало вероятна? Я утверждаю прямо противопложенное - в общем случае нет ни обратной, ни прямой совместимости. Но все продукты переносятся их разработчиками на новые версии и это вполне естественный процесс. Который нужно поддерживать и форсировать. > > Как тогда это соотносится с: > > положу 2.6.3 в сиз (завтра, наверно) кто им пользуется - будьте Вышеупомянутым образом. Разработчики Z портировали его на py23, причем заявлено что ближайшие версии Z будут несвместимы с py22 в любых проявлениях. > > Тут проблема очень простая, на самом деле. По своему предыдущему > (непитоньему) опыту я знаю, что у каждого продукта, если это не наколенный > скрипт для внутреннего потребления, есть maintaince cycle. То есть, грубо > говоря, период, когда мы _вынуждены_ поддерживать ту версию программы, Да. Я с этим согласен. Но, как я уже сказал - для перехода на python23 был 1 (один) год. Времени достаточно. Для дальнейшей поддержки заказчиков есть дистрибутив master 22 который можно им ставить. В ALM3, вполне возможно, python22 не будет. Во всяком случае - мой голос "ЗА". > которую установили заказчику. Причем, поддерживать именно в том виде, в > котором установили - максимум, мелкие патчи, которые не меняют приложение > кардинально. Любой апдейт из Сизифа - это уже кардинальное изменение положения. В то же время, по опыту патчей к Zope, за редчайшим исключением, переход py21 - py22 и py22 - py23 не есть кардинальное изменение положения. > У меня сейчас, возможно, образуется ситуация, когда я буду просто не в > состоянии говорить: "а мы с разработчиками тут переехали на новый [питон], > он рулит, но со старым [питоном] совместимости больше нет, и давайте мы вам > за _ваш_ счет произведём апгрейд". За свой, понятное дело, тоже не очень > хочется :-)). Вот и подпрыгиваю :-). Я вас очень хорошо понимаю. Я прохожу через это каждое лето. В тех случаях, когда оплата перехода оказывается невозможной - я не апдейчу клиентские сервера до нового мастера, а ограничиваюсь паккетами из updates. Соответственно, новый софт клиент не получает и это логично: за новые версии надо платить. Но всю разработку мы ведем только на последних версиях, соотв. если наш старый клиент хочет новые фичи, которых не было в старых версиях софта - ему приходится ставить новую версию и нашего софта, и его окружения. И, по факту, я не в силах поддерживать в новых версиях продуктов ни совместимость с python21 / 22, ни совместимость с Zope251, ни совместимость с omniORB3: просто не было в них тех возможностей, которые используют новые версии наших продуктов. И это вполне естественно. Так что, мое мнение: 1. Сизифус - для разработчиков, для которых актуален немедленный переход на новые версии софта; 2. Поддержка старых инсталляций осуществляется исключительно за счет updates старых дистрибутивов, а не за счет апдейта из сизифа; 3. Обновление старых инсталляций в связи с переходом на новые версии софта требует перехода на послендий оффициальный релиз дистрибутива. По-моему это логично и в подавляющем большинстве случаев можно объяснить клиенту, который выбирает для себя вариант подходящий по деньгам и функционалу. ЗЫ: Когда я закончил институт и делал свой первый проект, я не придерживался первого пункта и наступил на очень большие грабли: к моменту сдачи проекта весь софт, на котором он был построен безнадежно устарел. С его сдачей возникли проблемы... Теперь для меня разработка на последних релизах, а лучше даже на альфа- и бета- версиях - непреложное правило от которого я стараюсь не отходить и другим советую тоже самое. -- WthBstRgrds -- Андрей Орлов -- --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org --- ----------------------------------------
next prev parent reply other threads:[~2004-01-11 10:45 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-01-10 11:58 ` Andrey Orlov 2004-01-11 3:28 ` Alexey Morozov 2004-01-11 10:45 ` Andrey Orlov [this message] 2004-01-11 19:23 ` [devel] Re: [sisyphus] ðÉÔÏÎØÉ ÍÏÄÕÌÑ Alex Ott 2004-01-11 21:07 ` [devel] Re: [sisyphus] Питоньи модуля Andrey Orlov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=200401111345.20731.cray@neural.ru \ --to=cray@neural.ru \ --cc=devel@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git