Hey Greg, (I am not part of the releng team so all of this is just what I would do if I was in a similar situation.)
This is a very specific use case. You should probably revisit your algorithm. The versioning scheme is not etched in stone. I don't know if this can get included for M1a on Monday. But even if it can, in the future, I doubt if your use case is strong enough to call for a milestone respin. To increase your chances that this gets included in M1a, I suggest you file a bug and prepare a Gerrit. Again, I am not part of the releng team but this is what I would do, especially on a Sunday :) Cheers, Wim On Sun, Oct 11, 2020 at 11:51 AM Gregor Schmid <gschm...@qfs.de> wrote: > > Hi Sravan, > > thanks a lot for getting back. > > I don't really know enough about the Eclipse CI system to comment, but > speaking in general, if an automated build script fails half way I > would expect a hard reset of HEAD to the previous commit before > rerunning the script. > > Anyway, my use case is as follows: > > Our tool QF-Test does UI test automation for Eclipse/SWT applications. > To that end we need to instrument SWT code. In earlier versions (this > goes back to Eclipse 3.1) this was done by replacing the SWT jar, > nowadays we use a Java agent to just swap the few classes we need to > modify at runtime. Lest anybody wonders, the whole thing is > license-conform and we make our patches publicly available via gitlab: > > https://gitlab.com/qfs/qfs-swt-patches > > So we're now shipping QF-Test with SWT instrumentation jars for SWT > versions ranging from 3.7 to 4.17 with 4 versions added per year. > > My specific problem is that when QF-Test encounters an swt.jar file > for instrumentation or an SWT class being loaded at runtime it needs > to find out which SWT version that is in order to determine the > required instrumentation classes. The only reliable way to do that is > getting hold of the SWT Library class and reading its version numbers. > And then we map those numbers to version names like '4.17' and > '2020-09'. With the skipped MINOR_VERSION my code now mixes up 4.18 > and 4.19. > > It's easy to fix or work around, of course, but my case is just one > example and there's a lot of code out there based on or working > against SWT. I'm a big fan of maintaining consistency and I think that > all such tools as well as code using SWT.getVersion() require and > deserve consistent version numbering. > > I'd be very happy If this could still be fixed. 4.18M1 now stands at > 4940R9. If you fix that now and change it to 4938R* and later take > care to start the real 4.19 with 4940R10 or higher there won't be any > duplicates and the only misnumbered releases will be a few early-stage > 4.18 releases nobody cares about instead of all official releases > starting with 4.18. > > Thanks for considering it and best regards, > Greg > > "Sravan K Lakkimsetti" <sravankum...@in.ibm.com> writes: > > > Hi Gregor, > > > > We have a job to upgrade the version number for each release. The problem > > here is that job failed when we ran > > https://ci.eclipse.org/releng/job/SWT-new-release/19/ . Se we had to run > > the job again to get the version numbers set properly. Looks like the > first > > run did a partial commit. That caused this trouble. > > > > Could you please elaborate the use case where your are using this number? > > It will be helpful in understanding the problem you are facing. And take > > necessary action from our side. > > > > Thanks > > Sravan > > > > -----Original Message----- > > From: Gregor Schmid <gschm...@qfs.de> > > Sent: 10 October 2020 23:26 > > To: platform-dev@eclipse.org > > Subject: [EXTERNAL] [platform-dev] Inconsistent version change in SWT > 4.18 > > > > Hi all, > > > > I just started porting our software to SWT 4.18M1 and am mystified by a > new > > break in the versioning scheme: > > > > Can somebody please shed some light on why MINOR_VERSION in > > org.eclipse.swt.internal.Library was changed from 936 to 940 instead of > 938 > > for SWT 4.18? > > > > My understanding was that starting with eclipse 4.10 - due to running out > > of digits in the old numbering scheme - Library constants were switched > to > > MAJOR_VERSION ("always" 4), MINOR_VERSION and REVISION, with > MINOR_VERSION > > being incremented by 2 for each quarterly release. > > > > Looking at the gitlab source I see tags 4936* followed by 4940* but none > > for 4938. > > > > Git blame shows the latest MINOR_VERSION change coming from releng bot on > > Sep 3, commit a499996d56afce9859b8773d4b91bc8ba2b11d58 > > > > Curiously, the change was from 938 to 940. The previous change from > > 936 to 938 happened on the same day, commit > > f6e1d955d81678d06d8e4f2c13dc83803ccb9fa1 > > > > So why did that happen? Was the version update triggered twice by > accident? > > Did anybody notice? > > > > More importantly, what's going to happen now? It is my hope that we are > not > > slaves to the build system and somebody can and will override this > > manually. If the 4.18 MINOR_VERSION stays at 940, all code that tries to > > map old-style version numbers to Library *_VERSION constants will break > and > > need tweaking for yet another special case. > > > > I strongly suggest that this should get fixed sooner rather than later > lest > > more people start to adopt 4.18 and implement workarounds. > > > > Best regards, > > Greg > > > > -- > > Gregor Schmid > > > > E: gregor.sch...@qfs.de > > T: +49 8171 38648-11 > > F: +49 8171 38648-16 > > > > Quality First Software GmbH | www.qfs.de Tulpenstr. 41 | 82538 > Geretsried | > > Germany GF Gregor Schmid, Dr. Martina Schmid, Karlheinz Kellerer HRB > > München 140833 > > > > The data protection information in accordance with the EU General Data > > Protection Regulation applies to authorized representatives / authorized > > representatives of "legal persons" in accordance with Art. > > 12 ff. DS-GVO > > https://www.qfs.de/fileadmin/Webdata/pdf/en/dsgvo.pdf > > > > _______________________________________________ > > platform-dev mailing list > > platform-dev@eclipse.org > > To unsubscribe from this list, visit > > https://www.eclipse.org/mailman/listinfo/platform-dev > > > > _______________________________________________ > > platform-dev mailing list > > platform-dev@eclipse.org > > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev > > > > -- > Gregor Schmid > > E: gregor.sch...@qfs.de > T: +49 8171 38648-11 > F: +49 8171 38648-16 > > Quality First Software GmbH | www.qfs.de > Tulpenstr. 41 | 82538 Geretsried | Germany > GF Gregor Schmid, Dr. Martina Schmid, Karlheinz Kellerer > HRB München 140833 > > The data protection information in accordance with the EU General Data > Protection Regulation applies to authorized representatives / > authorized representatives of "legal persons" in accordance with Art. > 12 ff. DS-GVO > https://www.qfs.de/fileadmin/Webdata/pdf/en/dsgvo.pdf > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
