| Re: [platform-dev] Inconsistent version change in SWT 4.18 |
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" <sravankumarl@xxxxxxxxxx> 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 <gschmide@xxxxxx>
> Sent: 10 October 2020 23:26
> To: platform-dev@xxxxxxxxxxx
> 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.schmid@xxxxxx
> 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@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
>
> _______________________________________________
> platform-dev mailing list
> platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
>
--
Gregor Schmid
E: gregor.schmid@xxxxxx
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@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev